Track checkout.started in the VTEX checkout funnel#1
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds
checkout.startedtracking to the VTEX checkout funnel so we can capture checkout entry in the environment where the storefront pixel cannot run.The new event is triggered from the initial
getOrderForm()load and subsequentorderFormUpdated.vtexupdates, but it is deduped once perorderFormIdper browser session. That gives us Shopify-like checkout entry semantics without relying on a VTEX hook that only fires on the first modifying request.This change also keeps the event attribution safe and retryable:
checkout.startedalways carries the current checkout-shaped user payload, even when email or phone are not available yet, so the event does not inherit a stale remembered Hellotext identity from cookiesHellotext.track(...)succeeds, and in-flight sends for the sameorderFormIdare suppressed so concurrent updates do not double-send the eventWhat Changed
Added a checkout-specific helper in
src/checkout.jsthat trackscheckout.started, dedupes byorderFormIdinsessionStorage, suppresses duplicate in-flight sends, and only marks the event as delivered after a successful Hellotext response.Updated the checkout funnel entrypoint in
src/funnel.jsso the initialgetOrderForm()load andorderFormUpdated.vtexboth feed a shared order-form handler. The funnel still identifies the shopper when email or phone is available, and now also emitscheckout.startedwith the normalized VTEX order and user payloads.Expanded the funnel test coverage to verify the initial event, same-order dedupe, new-order retracking, pending-request suppression, retry-after-unsuccessful-response, and the anonymous-checkout case where we still send the current checkout user payload. The README and built
dist/funnel.jsbundle were updated to reflect the new behavior.Why This Matters
Without this event, the VTEX SDK only captured shopper identification updates and the final
order.placedevent. We were missing the actual point where a shopper enters checkout, which is the key signal needed for abandoned-checkout attribution and parity with the Shopify pixel'scheckout.startedflow.This PR adds that signal while keeping the VTEX implementation safe for real traffic. It avoids stale identity leakage from remembered Hellotext cookies, does not burn the dedupe key on failed requests, and prevents rapid VTEX updates from producing duplicate
checkout.startedevents for the same order form.Verification
yarn testyarn build