Customer and decisioning data personalises a store visit through 1 entry point: the Visitor API. Your data platform posts what it knows about a visitor, and the platform uses that data on every touch-point the visitor meets — the display at the door, the mobile site on their phone, the staff tablet, and the insights HQ sees afterwards.

A visit, end to end

  1. A customer finds a branch through the store locator on your website and books an appointment because lunchtime waits are long.
  2. The confirmation SMS opens the branch's mobile store site with directions and a personalised offer.
  3. On arrival, the customer scans the QR code on the entrance display, checks in for the appointment and provides an identifier so staff can find them.
  4. The display plays the offer that matches their profile; scanning it opens the offer page on their phone.
  5. Staff are notified of the arrival. When they pick the customer up from the queue, the relevant insights appear, including that the customer engaged with the offer on the display.
  6. At HQ, the whole journey is visible: website visit, wait time, serve time and which offers the customer engaged with.

Where the data comes from

The platform does not hold your customer data. Your customer data platform (CDP) or decisioning solution looks the visitor up by an identifier the platform has captured — usually a hashed email address or hashed mobile number from a queue join, a QR Control scan or an appointment — and posts the result to the Visitor API. The decisions to make before you connect are in Trigger campaigns from customer or decisioning data.

The Visitor API feed

The feed is 1 POST request to https://<your-platform-domain>/location-api/visitor/feed with a Content-Type: application/json header and an apikey header holding a secret from Platform Admin → API Authentication. The body is a JSON object.

FieldValue
device_idAny value; must not be blank
device_typeThe visitor's device type
sourceAPP or STORE_TABLET
uuidThe store's Store Code exactly as shown in Stores / Branches
uuid_typeAlways STORE_CODE
display_idThe display's ID from its detail page URL in Displays & Devices. Omit it to target every display in the store
first_nameThe visitor's first name, used in tokens such as ${FirstName}
events, page_viewRecent activity from your app or website
product_holdingsAn array of the products the customer holds

Other supported customer and decisioning fields are age, gender, product type, plan type, plan value, purchase history, platform data and visitor segments. Sending the feed with blank values stops the campaigns it triggered.

What the platform does with it

  • Displays. Each campaign's targeting rules under Visitor / Customer Data are evaluated against the feed. A matching triggered campaign plays on the display named in the feed, or on every display in the store.
  • Staff tablet. When staff pick a visitor up from the queue, the visitor's recent interactions and profile data are shown — see View a visitor's recent interactions and profile data.
  • Insights. Campaign playback and engagement are recorded against the visit for Insights / Analytics.

Proving it before you integrate

You can demonstrate the whole flow internally with a REST client app on a phone posting sample feeds to a test store. The procedure is in Trigger campaigns from customer or decisioning data.