Table 1: Event properties to deprecate for Ecommerce Purchase
Ecommerce Event Property | Conclusion | Comment | ||||||
---|---|---|---|---|---|---|---|---|
deliverySurchargeFeeAmount |
| |||||||
mparticle_amplitude_should_split |
| |||||||
products.added_to_cart_time_ms |
| |||||||
Transaction POS |
Info already logged in Restaurant POS property | |||||||
Value Threshold 10 Met |
| |||||||
Value Threshold 5 Met |
| |||||||
baseDeliveryFeeAmount |
| |||||||
branch_service_mode |
| |||||||
customer_event_alias |
| |||||||
quotedFeeAmount |
| |||||||
totalDeliveryOrderFeeAmount |
| |||||||
hasSavedDeliveryAddress |
It’s important information to know the # of users making order with a saved delivery address to gather insights on store locator features | |||||||
hasSelectedRecentAddress |
It’s important information to know the # of users making order with a recent delivery address to gather insights on store locator features | |||||||
Pickup Mode |
Service Mode indicates between Pick up and Delivery. Pick up mode indicates whether the Pick up was Eat in, Take away, Table service. | |||||||
revenue |
| |||||||
Restaurant Name |
| |||||||
Restaurant Number |
| |||||||
products.id |
| |||||||
products.position |
| |||||||
Restaurant Drive Thru Lane Type |
| |||||||
Restaurant Front Counter Closed |
| |||||||
Restaurant Has Breakfast |
| |||||||
Restaurant Has Burgers For Breakfast |
| |||||||
Restaurant Has Catering |
| |||||||
Restaurant Has Curbside |
| |||||||
Restaurant Has Dine In |
| |||||||
Restaurant Has Drive Thru |
| |||||||
Restaurant Has Front Counter Closed |
| |||||||
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 Latitude |
| |||||||
Restaurant Longitude |
| |||||||
Restaurant Number Drive Thru Windows |
| |||||||
Restaurant POS |
| |||||||
Timed Fire Minutes |
Could be related to queuing system and thus needed on a global state | |||||||
products.cartId |
| |||||||
products.comboChild |
| |||||||
products.custom_attributes.cartId |
| |||||||
products.custom_attributes.comboChild |
| |||||||
products.custom_attributes.isDonation |
| |||||||
products.custom_attributes.isExtra |
| |||||||
products.custom_attributes.Item Level |
| |||||||
products.custom_attributes.L1 |
| |||||||
products.custom_attributes.L2 |
| |||||||
products.custom_attributes.L3 |
| |||||||
products.custom_attributes.L4 |
| |||||||
products.custom_attributes.L5 |
| |||||||
products.custom_attributes.rewardItem |
| |||||||
products.custom_attributes.sublevelItems |
| |||||||
products.isDonation |
| |||||||
products.L1 |
| |||||||
products.L2 |
| |||||||
products.L3 |
| |||||||
products.L4 |
| |||||||
products.L5 |
| |||||||
products.total_product_amount |
| |||||||
Table 2: Event properties to add to Ecommerce Purchase
Ecommerce Event Property | Conclusion | Comment | ||||||
---|---|---|---|---|---|---|---|---|
Promotional Code |
If a user makes a purchase with a promo code, we don’t save that attribute in the purchase event | |||||||
Promotional Code Submitted |
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 another event | |||||||
Detail Promo Code Submited |
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 | |||||||
Coupons |
We already have a property called Coupon Applied (True/False) and a property called Coupon ID with the Sanity ID of the coupon applied. PS: For naming consistency in the code, Coupon Applied and Coupon ID will be changed to Offer Applied and Offer ID | |||||||
Delivery fee |
We already have that property where we specify the amount of delivery fee the user has been charged | |||||||
Device Date |
At the time of the purchase, the event will fire with a certain timestamp. Device Time is planned to be a user property as well | |||||||
Donation amount |
We already have exactly the Donation Amount property live in Backend Purchase. It is currently showing value 0 because there are no donations. Once we have donations, check the values are being logged correctly. | |||||||
Payment Status |
We have 2 events: order_status_change and delivery_status_change where the order status is recorded | |||||||