Where a guest has visited a venue and there is a digital footprint which doesn't neatly fit into any of our pre-existing native categories (e.g. table booking, purchase history, loyalty interaction, voucher redemption, WiFi login, ticket), we also have the option to store a Proof of Presence (PoP) without full context.
Having this "PoP" data stored historically is useful to measure and target guests based on recency and frequency.
To store a PoP, add a pops object as you write a contact record.
"account_id": 3,"email: "johnsmith@gmail.com",//...etc..."pops" : [ {"unit_id":123,// where the PoP happened"type_id":2// Member check-in, feedback submission etc"datetime" : "2021-06-01 00:00:00"// When the pop happened }]
PoP Types
To retrieve a list of pop_type_ids you can call the /pop/types endpoint.
Note that storing a PoP is not a substitute for sending a full record of an interaction in scenarios where we have full native storage fields. For example: Bookings, WiFi, Purchase History, Loyalty, Voucher Redemptions and Tickets. You should always use our native storage where we have an appropriate category.
