This event is supported on all of our templates.
Triggered after a search for every product that was found in at least one of the B&M (Find In Store) locations.
Event specific data points
| store_id | The ID of the store. The table this value links to is dependent on the feed the store came from. |
| store_name | The name of the store, which should match the entry store_id links to. This is included so when generating reports we don’t need a CORE db connection. |
| allProductsSearched | true if all products were included in the search and false otherwise. |
This event is handled in a special way. The data above is what will be stored inside the TimeStream database, but the data that is transmitted from the locator is structured differently. The locators allow for searching up to 175 products at once, and there’s the potential for all 175 products being found at 10+ stores. This would result in needing to send over 1750 events to our API, which could cause negative side effects when scaling for thousands of locators. To counteract this problem this event is transmitted in a way so there will only be 1 event per product.
The locator will send a single event with the store_id and store_name values being excluded and in their place a single stores value will be sent. This stores value consists of an array of objects with each object in this array containing an id and name value. The id and name values correlates to the store_id and store_name values respectively and the API will explode out the stores array into individual database entries.
For example, the below stores value would appear inside a single event but would result in two database entries in TimeStream:
[{ id: 1, name: "Destini"},{ id: 2, name: "Spins"}]This event also inherits all of the default data points.
Comments
Article is closed for comments.