Checkout Step Encountered

[jeffkush-sdi]

Checkout Step Encountered

Sample EDDL Sequence/datalayer values.

QA: https://github.com/searchdiscovery/Apollo-Documentation-Connected-Vehicle/issues/4#issuecomment-1896454126

QA JAN 26: Comment

[jeffkush-sdi]

CHECKOUT STEP ENCOUNTERED STATUS: Check Out Step Encountered event does appear to be firing correctly as a bracketed event from datalayer POV. The initial event after authentication may need adjustment. (Snapshot) review in progress...

https://cwp.sit.siriusxmguardian.com/manage (after initial authentication)

1. TODO: [FWW adjust hit type]
2. ISSUE: Expectation is that since the user is authenticated and the UX seems to denote an 'active' product/package we would expect that this 'active' product would be available in the event ie we would see some values in the datalayer product array. NOTE: the below screenies are just after AUTH > landing
3. 
4. 
5. We are seeing a more correct event structure/values as we traverse further into the UX flow, this only seems relevant on the initial landing page after authentication.

[jeffkush-sdi]

@Shocopop

'Checkout Step Encountered' DataLayer QA

Summary: Event/Schema in datalayer look correct. Generally, the issue we see is just 'too many' Checkout Step Encountered events in the datalayer. ie for each 'checkout step' it seems like several groups of bracketed events fire, whereas the expectation would be a single set of bracketed events. (see screenies below)

01 Use Case (Landing+auth - Initial Step): https://cwp.sit.siriusxmguardian.com/manage

Datalayer event schema looks correct and the event does appear to be bracketed with a closing Page Load Completed datalayer event. In this use case the expected events Product Listing Displayed + Checkout Step Encountered are bracketed properly. Additionally, since this is the first 'step' there is no expectation that the PRODUCT ARRAY would have any products @ this point in the subscription flow.

ISSUE

• Seeing several (too many) dataLayer pushes for Checkout Step Encountered. This may not be related directly to this event but it will send a server hit on each one of these pushes, which include Checkout Step Encountered
• This 'multiple' dataLayer pushes issue is documented in other Project Events...sometimes we see the correct dataLayer sequence ie Expected sequence (1x) after user is authenticated and just lands on 'manage' page (see below); other times I see multiples as in below screenie... -- Page Load Started --Checkout Step Encountered --Product Listing Displayed --Page Load Completed

(the datalayer right after authentication > landing on manage)

02 Use Case (Landing+auth - Payment Step): https://cwp.sit.siriusxmguardian.com/manage

Event Schema /Parameters (CORRECT)

03 Use Case (Landing+auth - Review Step): https://cwp.sit.siriusxmguardian.com/manage

Event Schema /Parameters (CORRECT)

Order Placed step

[FWW] To Review Server Calls/Rules... cc @msawlorSDI

[jeffkush-sdi]

@Shocopop ISSUE: We wanted to ensure the the productInfo{} object and its parameters are consistent thru the flow. Viewing the attached screenie, you'll notice that in row index 18 we added a product to cart and its related productInfo BUT if you follow the next dataLayer ie index 23 (checkout step encounter - review) you'll notice that the productInfo{} parameters are not the same as in previous 'add to cart' dataLayer push. The expectation is these values should flow consistently as we progress thru the subscription flow.

[jeffkush-sdi]

@Shocopop STAGE: NEW ISSUE? So working thru QA on STAGE with 'new' SXM user. Appears this user needs to add an address to his account. This injects a new checkout step into the flow (not seen in other .sit flows). I'm seeing a disconnect between what this step contextually represents (address step) VS what I see in the dataLayer value; in this case 'Payment'. Step/value sync issue? NOTE: This appears to affect the Page Load Started event as well.

STAGE

[jeffkush-sdi]

@Shocopop in thinking further about this, I suppose you could say that the (address step + enter visa cc step...ie meaning the value of checkout step parameter may still be considered as payment) = ('payment' step); its really more a contextual question...how SXM might want to break this out. cc @msawlorSDI

[jeffkush-sdi]

Know we've been working thru the bracketing issue, in general, around checkout step encountered.

• Page Load Started
• (applicable event: Checkout Step Encountered)
• Page Load Completed

[jeffkush-sdi]

@Shocopop looks pretty good, thank you. Will review w/ @msawlorSDI on MON.

QA .SIT

NO ISSUE: We'll want to check again in .STG since we know the user may have additional steps in the flow, but this use case looked good.

(...in progress verify the added product IDs stay consistent thru checkout flows, this is user dependent in some case > .STG)

(screenie from Add to Cart) (Ids appear correct in this user's payment step)