| Info |
|---|
Purchase event optimizations will be implemented under the assumption that i) the ‘Backend Purchase’ event will become the source of truth since cookie settings are expected to significantly impact the volume of front-end events forwarded to Amplitude ii) the ‘eCommerce Purchase’ front-end event will be deprecated after the optimisations to the back-end event are completed |
| Table of Contents | ||
|---|---|---|
|
Table 1: Event
...
Properties to add to Backend Purchase
...
Event Property |
|---|
hasSelectedRecentAddress
It’s important information to know the # of users making order with a recent delivery address to gather insights on store locator features
Rewards
totalDeliveryOrderFeeAmount
Upsell Total
Comment |
|---|
Address Type
Has Upsell
hasSavedDeliveryAddress
It’s important information to know the # of users making order with a saved delivery address to gather insights on store locator features
Promotional Code | If applied to order |
Product Count | Cart Data |
products | Cart Data |
products.added_to_cart_time_ms | Cart Data |
products.cartId | Cart Data |
products.comboChild | Cart Data |
products.custom_attributes.cartId | Cart Data |
products.custom_attributes.comboChild | Cart Data |
products.custom_attributes.isDonation | Cart Data |
products.custom_attributes.isExtra | Cart Data |
products.custom_attributes.Item Level | Cart Data |
products.custom_attributes.L1 | Cart Data |
products.custom_attributes.L2 | Cart Data |
products.custom_attributes.L3 | Cart Data |
products.custom_attributes.L4 | Cart Data |
products.custom_attributes.L5 | Cart Data |
products.custom_attributes.rewardItem | Cart Data |
products.custom_attributes.sublevelItems | Cart Data |
products.id | Cart Data |
products.isDonation | Cart Data |
products.isExtra | Cart Data |
products.Item Level | Cart Data |
products.L1 | Cart Data |
products.L2 | Cart Data |
products.L3 | Cart Data |
products.L4 | Cart Data |
products.L5 | Cart Data |
products.name | Cart Data |
products.position | Cart Data |
products.price | Cart Data |
products.quantity | Cart Data |
products.rewardItem | Cart Data |
products.sublevelItems | Cart Data |
products.total_product_amount | Cart Data |
Table 2: Event
...
Properties to deprecate
...
from Backend Purchase
| Info | ||||
|---|---|---|---|---|
In the Excel file, all the properties for the Backend Purchase event are listed. rbi does not recommend to deprecate any event properties from the Backend Purchase event. Please check whether there is any property that you recommend to be deprecated and add it to the table with a justification why. As a reference, the Excel file also contains the FE eCommerce Purchase event along with its properties.
|
Ecommerce Event Property | Conclusion | rbi Comment |
|---|---|---|
Restaurant Drive Thru Lane Type | ||
Restaurant Has Breakfast | ||
Restaurant Has Burgers For Breakfast | ||
Restaurant Has Catering | ||
Restaurant Has Curbside | ||
Restaurant Has Dine In | ||
Restaurant Has Drive Thru | ||
Restaurant Has Home Delivery | ||
Restaurant Has Mobile Ordering | ||
Restaurant Has Parking | ||
Restaurant Has Playground | ||
Restaurant Has Table Service | ||
Restaurant Has Take Out | ||
Restaurant Has Wifi | ||
Restaurant LatitudeID | Use Restaurant LongitudeNumber instead | |
Restaurant IDLatitude | ||
Use Restaurant NumberLongitude |
Table 3: Event properties to potentially add to Backend Purchase
...
later
Property |
|---|
Conclusion
posType
| Status | ||||
|---|---|---|---|---|
|
use ‘posType’ property in ‘In-Store Loyalty Transaction Claimed’ events
Rewards
| Status | ||||
|---|---|---|---|---|
|
Comment |
|---|
Promotional Code
| Status | ||||
|---|---|---|---|---|
|
If a user makes a purchase with a promo code, we don’t save that attribute in the purchase event
Promotional Code Submitted
(Succesful|Fail)
| Status | ||||
|---|---|---|---|---|
|
Not clear what’s the difference vs the 1st one. Once making the purchase, the promotional code will be used. Code applied status should be a property of an interaction event
Detail Promo Code Submited
| Status | ||||
|---|---|---|---|---|
|
Not clear how to have it implemented in the Backend Purchase as the purchase is the final state. The promo code being submitted comes at an earlier stage and would be covered as a property of the interaction event
Coupons
| Status | ||||
|---|---|---|---|---|
|
We already have a property called Offer Applied (True/False) and a property called Offer ID with the Sanity ID of the coupon applied.
Donation amount
| Status | ||||
|---|---|---|---|---|
|
We already have exactly the Donation Amount property live in Backend Purchase. It is currently showing value 0 because there are no donations.
Tax Amount
| Status | ||||
|---|---|---|---|---|
|
This is always ‘0.0’ on FE & BE Purchase Events
What is the expected calculation?
deliveryFeeAmount
| Status | ||||
|---|---|---|---|---|
|
Existing as deliveryFeeAmount
deliveryDiscountAmount
| Status | ||||
|---|---|---|---|---|
|
This is always ‘0' or 'none’ on FE purchase events
What is the expected calculation?
deliveryGeographicalFeeAmount
| Status | ||||
|---|---|---|---|---|
|
This is always ‘0' or 'none’ on FE purchase events
What is the expected calculation?
Device Time
| Status | ||||
|---|---|---|---|---|
|
For BE events, Device Time is not available but each individual event has a timestamp
Use the calendar and enable Time Range to filter events between times
Is Kiosk
| Status | ||||
|---|---|---|---|---|
|
This is always ‘none’ or ‘false’ on FE purchase events
Use ‘posSystem' property in 'In-Store Loyalty Transaction Claimed’ events
Payment Status
(pending|done)
| Status | ||||
|---|---|---|---|---|
|
The oder status will always be the same ('INSERT_SUCCESSFUL') when the BE purchase event is fired so is not useful
posSystem
| Status | ||||
|---|---|---|---|---|
|
use posSystem property In-Store Loyalty Transaction Claimed events for kiosk purchases
Can we add Offer ID and Offer Applied to In-Store Loyalty Transaction Claimed events?
Address Type | This information is not stored on backend, requires further analysis |
deliveryServiceFeeAmount | Requires analysis to check feasibility of adding |
deliverySmallCartFeeAmount | Requires analysis to check feasibility of adding |
Mobile number (if not matching stored mobile number) | Requires analysis to check feasibility of adding |
hasSelectedRecentAddress | This information is not stored on backend, requires further analysis |
hasSavedDeliveryAddress | This information is not stored on backend, requires further analysis |
Rewards | Requires analysis to check feasibility of adding 'Add Reward Applied' and 'Reward |
deliveryServiceFeeAmount
| Status | ||||
|---|---|---|---|---|
|
ServiceFeeAmount is available but always ‘0' or 'none’ on BE purchase events
Also, deliveryServiceFeeAmount is always ‘0' or 'none’ on FE purchase events
What is the expected calculation?
Expected to be applicable to BK ES
deliverySmallCartFeeAmount
| Status | ||||
|---|---|---|---|---|
|
SmallCartFee is available but always ‘0' or 'none’ on BE purchase events
What is the expected calculation?
Expected to be applicable to BK ES
Source Page
| Status | ||||
|---|---|---|---|---|
|
FE events have to be used for user interaction
Transaction Id
| Status | ||||
|---|---|---|---|---|
|
ID |
Upsell Simplified Enabled
' |
Is upselling currently available?
This property is unavailable for BE events
Upsell Total
| Status | ||||
|---|---|---|---|---|
|
if feasible, to be added
Address Type
| Status | ||||
|---|---|---|---|---|
|
Only available for FE events
hasSavedDeliveryAddress
| Status | ||||
|---|---|---|---|---|
|
Only available for FE events
Mobile number used for orders which is not same as default number in profile?
| Status | ||||
|---|---|---|---|---|
|
Luke to check
...
Upsell Total | Requires analysis to check feasibility of adding |
| Info |
|---|
Need to check why existing property ‘Tax Amount’ only returns 0.0 value! |