Event feed reporting
Overview
The Event feed service was created to meet the requirements of customers who require more control over the time and format of shopper events occurring within their stores to allow for a more flexible and scalable integration with back-office systems such as Point of Sale and ERP. The Event feed service is targeting three types of events, 1)Ordering, 2) Payment and 3) Shopper.
The Event feed solution guide is applicable for all retail integration models supported by Amazon Just Walkout services.
Prerequisites
The following are the prerequisites to enable retailers to take advantage of the Event feed solution.
AWS EventBridge: the sample solution depends on AWS EventBridge service to receive events from the Amazon systems. You will also need to have permissions to create, update AWS EventBridge resources and IAM roles and policies.
Just Walk Out Store: the Event feed solution uses cart event data generated in an operational Just Walk Out store.
AWS account: An AWS account is required to utilize the Event feed solution. For steps on how to get an AWS account follow steps here.
Common use cases
Below are some sample use cases to enable most flexibility and provides easy access to data across multiple merchant accounts and Just Walk Out stores. Select the most applicable use case for your company based on your reporting need and technical solution complexity.
Stage incoming cart data on an S3: this approach works best for customers that have already invested in mechanisms to ingest reporting data from an S3 or a file mount. This allows you to control the frequency of generating the event file to you need as well as doing schema translation to match your reporting intake process.
Store incoming cart data into a document database: this approach allows you to pass the incoming cart data to a data store, in this case a document database to enable use cases such as available inventory in a store in near time and alerting to reaching a threshold Pipe the incoming event into a destination API: this use case allows you to pass the payload to an API endpoint you might have. EventBridge supports most common authorization mechanisms to provide maximum flexibility. Note: there are additional integration options so please consult the EventBridge documentation for more detailed use cases.
High level event flow
A shopper will complete their trip at an Amazon Just Walkout store. As soon as the shopping trip ends, Amazon will complete the validation process and send the event to the process in Figure 1
1- The EventBridge service in the Amazon system will use a pre-configured EventBus endpoint to deliver the cart data. For steps on how to onboard to the Amazon system, see below. For steps on how to create an event bus see steps here.
2- As soon as the event is received in the customer account, it will validated against a rule that you have configured in your EventBridge. The event validation must comply with the Amazon event schema to ensure delivery of the cart events. For steps on how to configure EventBridge rules, see here. Below is a sample of event rule based on current cart schema. Note that the event schema can change so please review the latest documentation from Amazon.
{
"source": [
"AmazonEventsService"
],
"detail-type": [
"CART"
]
}
3- Once the event has been validated, the event data will be routed to the target defined in the EventBridge. Event bridge supports multiple types of targets. Please select the applicable target for your company. For steps on how to configure a target for an EventBridge rule, see here..
4- Depending on your use case you can process the incoming event. For an example of an event received from the Amazon systems see below
{
"version": "0",
"id": "4fee1921-6107-fa98-725f-ec0ad40889a0",
"detail-type": "CART",
"source": "AmazonEventsService",
"account": "<ACCOUNT_ID>", // source AWS account
"time": "2024-12-1eventast-1", // event time stamp
"resources": [],
"detail": {
"eventId": "0f58b881-b6af-47cc-a1f6-c32c5149b583",
"eventName": "ORDER_CREATED", // Type of event
"storeId": "<TEST_STORE_ID>",
"eventPayload": {
"sessionId": "<SESSION_ID>", // Shopping trip identifier
"orderId": "<ORDER_ID>", // Internal Amazon order identifier used for returns
"SessionStartTime": 1734054600041, // Time when the shopper started shopping
"SessionEndTime": 1734637678088, // Time when the shopper left the store
"cartItems": [
{
"quantityValue": 1,
"quantityUnit": "unit",
"priceValue": 8,
"priceCurrency": "USD",
"taxValue": 0,
"merchantSku": "BT6SG662GF",
"taxDiscountValue": 0,
"taxCurrency": "USD",
"taxDiscountCurrency": "USD",
"listPriceValue": 8,
"listPriceCurrency": "USD",
"orderLineItemId": "0",
"promotionInfo": null
}
]
}
}
}
You can apply schema translation to match the interface or input to any of your data ingestion targets.
For a sample Python Lambda solution to process the incoming message and store into an S3 file see below
-
When the incoming message is matches the Eventbus rule, the event is passed to the DataEmissions lambda
-
The Data emissions lambda is configured to record the incoming event to a file that will roll every minute using a configuration value. Full Lambda code below.
For CloudFormation template, sample Python Lambda on how to process incoming message please contact your Amazon team.