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 |
| |||||||
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 | |||||||
http://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 | |||||||
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 | |||||||