GA4 eCommerce Tracking Plan Template (United States) — 2025 Checklist

This is a practical, copy-ready checklist to plan, implement, and audit GA4 eCommerce tracking for U.S.-based stores. Use it for new builds, migrations, or quarterly audits. It reflects GA4’s recommended eCommerce events, “key events” terminology, Consent Mode v2 concepts, and U.S. privacy expectations.

Note: Event names, parameters, and validation steps are aligned with Google’s official guidance such as the Google Developers “Measure eCommerce” documentation and the recommended events reference.

---

1) Define Business Goals and KPIs (Pre‑Implementation)

• Map business objectives to measurable outcomes

  • Acceptance criteria:
    • Primary KPIs documented (revenue, AOV, conversion rate, cart-to-checkout rate, product performance).
    • User journeys identified (browse → cart → checkout → purchase → refund/returns).

• Choose which actions are “key events” in GA4

  • Decide which events you will mark as key events (e.g., purchase mandatory; optionally begin_checkout, add_to_cart, add_payment_info/add_shipping_info for funnel optimization). In Google Ads, imported GA4 key events become conversions for bidding; see Google’s overview in Link GA4 to Google Ads and import conversions.
  • Acceptance criteria:
    • A concise list of key events is approved by stakeholders.
    • Rationale recorded for each key event.
  • Common pitfalls:
    • Marking too many events as key events, diluting focus and cluttering Ads conversion setup.

• Establish naming and governance conventions

  • Acceptance criteria:
    • Standard event/parameter naming, currency format (ISO 4217), and owner/responsible roles documented.
    • Change-log and versioning approach agreed upon.

---

2) Design Your Data Model and Event Specifications

• Adopt GA4’s recommended eCommerce events

  • Include at minimum: view_item_list, view_item, select_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund; add view_promotion/select_promotion if using merchandising campaigns. See the Google Developers recommended events reference.
  • Acceptance criteria:
    • Final event list with triggers (where/when they fire) is approved.

• Define the items[] array (item-scoped parameters)

  • For product events, include item_id or item_name (at least one required), plus item_brand, item_category (hierarchy), item_variant, price, quantity, coupon, and affiliation as relevant. Reference the Google Developers item‑scoped eCommerce parameters.
  • Acceptance criteria:
    • Field-level spec completed for all item parameters (name, type, example, optional/required, source).
    • Category hierarchy rules defined (e.g., item_category, item_category2…5).

• Set currency and value correctly

  • For any monetary event (e.g., add_to_cart with value, begin_checkout, purchase, refund), include event-level currency (ISO 4217, e.g., USD) and value; ensure totals match what customers see.
  • Acceptance criteria:
    • currency and value present for all revenue-related events.
    • Price/quantity round-trips verified from source system to payload.
  • Common pitfalls:
    • Missing currency/value causes zero revenue in reports.

• Enforce transaction hygiene for purchases and refunds

  • Use a unique transaction_id per order; send purchase value as the order total (tax/shipping/discounts reflected). For refund, reference the original transaction_id and send items for partial refunds as needed. See the Google Developers “Measure eCommerce” documentation.
  • Acceptance criteria:
    • transaction_id uniqueness tested under concurrency and page reload scenarios.
    • Duplicate purchase prevention logic implemented (fires once per order), including reload protection.
    • Full and partial refunds payloads defined and tested.

• Track promotions (if applicable)

  • Send view_promotion and select_promotion with promotion_id and promotion_name; include creative_name/creative_slot when available.
  • Acceptance criteria:
    • Promotion parameters mapped from merchandising system.

---

3) U.S. Privacy and Consent (Consent Mode v2 Ready)

• Implement a consent/opt-out mechanism suitable for U.S. laws

  • Provide a “Do Not Sell or Share My Personal Information” link and honor state-level opt-outs and signals (e.g., GPC). See California’s guidance via the California Attorney General CCPA overview and the CPPA’s Opt-Out Preference Signals (OOPS) document.
  • Acceptance criteria:
    • Opt-out links visible and functional for relevant states.
    • GPC/OOPS signals recognized and acted upon in tag behavior.

• Configure Consent Mode v2 signals and timing

  • Ensure consent states (ad_storage, analytics_storage, ad_user_data, ad_personalization) are set early and updated on user interaction. Review Google’s Consent Mode v2 overview and use their consent debugging guide to verify behavior.
  • Acceptance criteria:
    • Consent state set before analytics/ads tags fire; updates propagate on user choices.
    • Debugging confirms denied states suppress storage and tags behave as configured.
  • Common pitfalls:
    • Sending personally identifiable information (PII) in GA4 parameters; avoid emails, phone numbers, or raw user IDs.

• Publish a clear privacy notice and data retention policy

  • Acceptance criteria:
    • Privacy notice discloses analytics practices and retention; data deletion processes documented.

---

4) Build the Implementation (GTM/gtag, optional server‑side)

• Prepare environments and access

  • Acceptance criteria:
    • Separate dev/stage/prod containers or workspaces; publish protocol defined.
    • Access control aligned to roles; audit log enabled.

• Instrument events with a standardized data layer

  • Acceptance criteria:
    • Data layer schema documented for each page/view and interaction.
    • All event payloads validated against the spec before tag configuration.

• Configure tags and triggers

  • Acceptance criteria:
    • GA4 Configuration/Consent settings consistent across tags.
    • Event tags for all planned eCommerce events created and named per convention.

• Set up cross-domain measurement (if applicable)

  • Acceptance criteria:
    • Linker configured for brand domain and payment/checkout domains to preserve sessions.
    • Test confirms no “direct/unassigned” revenue spikes from session breaks.

• Consider server-side tagging (optional)

  • Acceptance criteria:
    • If used, server container deployed with custom domain; client/server consent alignment tested.

• Implement duplicate‑purchase safeguards

  • Acceptance criteria:
    • One-time purchase firing logic verified under reloads, back-button, and retries.

---

5) Validation and QA Protocol

• Use DebugView and Tag Assistant for step-by-step testing

  • Validate each event’s parameters and items[] payloads end-to-end. Google documents these tools in the Consent debugging guide and throughout Developers references.
  • Acceptance criteria:
    • All events appear in DebugView with expected parameters and values.
    • Consent states visible and correct in the debugger before tags fire.

• Run controlled purchase tests

  • Acceptance criteria:
    • Test orders use a unique, recognizable transaction_id pattern (e.g., TEST-2025-0001).
    • currency, value, and items[] match the order confirmation and backend totals.
    • Reloading the confirmation page does not create duplicate purchases.

• Validate refunds

  • Acceptance criteria:
    • Full and partial refund flows tested; revenue impact verified in Monetization reports.

• Enable and verify BigQuery export for raw-data QA

  • Link GA4 to BigQuery and confirm dataset creation to support anomaly detection and payload audits. See Google’s BigQuery export overview for GA4.
  • Acceptance criteria:
    • Daily (and optional streaming) export enabled; basic QA queries run (duplicates, missing currency/value).

• Establish monitoring and alerting

  • Acceptance criteria:
    • Weekly checks on purchase volume/value, cart metrics, and direct/unassigned revenue.
    • Documented thresholds and escalation paths for anomalies.

---

6) Activation and Integrations

• Link GA4 to Google Ads and import key events

  • Follow Google’s instructions in Link GA4 to Google Ads and import conversions. In Google Ads, confirm auto-tagging and attribution settings.
  • Acceptance criteria:
    • Key events imported to Ads and marked for bidding as appropriate.
    • Attribution lookback windows and counting rules aligned across GA4 and Ads expectations.

• Confirm audiences and remarketing eligibility (within consent)

  • Acceptance criteria:
    • Audiences built using GA4 events/parameters; policies and consent states honored.

• Verify conversion value consistency between GA4 and Ads

  • Acceptance criteria:
    • Document expected variance from attribution differences; investigate outliers.

---

7) Reporting and Analysis Alignment

• Register custom definitions (including item scope)

  • If you send custom item or event parameters, register them in Admin > Custom definitions so they appear in reports. Google details item scope in the item‑scoped eCommerce parameters documentation.
  • Acceptance criteria:
    • Required custom definitions created with correct scope and exact parameter names.
    • Stakeholders informed of up to 24-hour availability delays.

• Build stakeholder-ready views

  • Acceptance criteria:
    • Standard Monetization reports reflect key events and purchase metrics.
    • Explorations for product, promotion, and funnel analysis set up and shared.

• Align nomenclature to “key events”

  • GA4’s current terminology uses “key events,” which, when imported to Google Ads, are treated as conversions there; Google outlines ongoing updates in the What’s new in Google Analytics help center.
  • Acceptance criteria:
    • Internal documentation and dashboards use consistent “key events” language.

---

8) Governance and Maintenance (Quarterly)

• Maintain version control and a change log

  • Acceptance criteria:
    • Every tag/config change recorded with date, author, purpose, and rollback notes.

• Schedule quarterly audits

  • Acceptance criteria:
    • Re-validate payloads (currency/value, items[], transaction_id uniqueness), consent operation, cross-domain linker, and Ads imports.

• Define ownership and incident response

  • Acceptance criteria:
    • RACI documented for analytics operations; escalation and rollback steps defined.

• Review privacy posture

  • Acceptance criteria:
    • Confirm Do Not Sell/Share and GPC handling; review privacy notice and retention settings in light of any new state laws.

---

9) Copyable Templates

9.1 Event Specification Template (copy this table and fill per event)

9.2 QA Run Log (copy and reuse for each test cycle)

9.3 U.S. Privacy Checklist (paste into your privacy program)

• Do Not Sell/Share link present on all pages where required; GPC honored.
• Consent Mode v2 states set before tags; denied states suppress storage.
• No PII in GA4 parameters; data retention documented; user rights process defined.

---

Quick Reference: Official Resources

• Event taxonomy and payloads: Google Developers “Measure eCommerce”
• Recommended events list: Google Developers GA4 recommended events
• Item-scoped parameters & custom definitions: Google Developers item‑scoped eCommerce
• Consent Mode v2 overview: Google Developers consent mode
• Consent debugging and Tag Assistant: Google Developers consent debugging
• GA4↔Google Ads linking/imports: Google Support: Link GA4 to Google Ads
• BigQuery raw export: Google Developers BigQuery export for GA4
• U.S. privacy baseline: California AG CCPA and CPPA OOPS (GPC)

Use this checklist as your working document. Duplicate it per property or brand, keep it versioned, and run the QA log every release cycle.