Book A Call
contact us

What First-Party Data Should Shopify Brands Send to Meta, Google and Klaviyo?

Picture of 1 At Bat Media Admin
1 At Bat Media Admin

The direct answer

Established Shopify brands should send each platform the minimum accurate, merchant-approved data needed for a defined measurement or activation job—not every field that happens to be available.

Start with clearly defined commerce events; exact timestamps; value and currency when the use requires them; a stable unique order, transaction or event identifier; only the identity fields approved through the merchant's existing privacy, security, contract and system-owner process; and the documented operational state governing the proposed use. Keep email and SMS subscription states separate from analytics, advertising and other data-use settings. Coordinate browser and server identifiers so one customer action is not counted twice, verify that each destination receives and processes the expected record, and assign an accountable owner to every integration.

Meta, Google and Klaviyo use those inputs differently. Better signal quality can improve the reliability of measurement inputs and platform diagnostics, but it does not prove attribution, incrementality, profitability or a causal reduction in CAC. Consent, disclosure, data minimization, platform terms and applicable law still govern what may be collected and shared.

Publisher disclosure: This guide is published by 1 At Bat Media, an ecommerce growth agency. It presents the agency's proposed operating safeguards for signal-quality decisions. It is not a Meta, Google, Shopify or Klaviyo standard, does not determine whether a specific data flow is lawful or appropriate, and is not legal, privacy or security advice.

Why “send everything” is the wrong rule

A bigger payload is not automatically a better signal. A brand can collect more fields and still have an unreliable system if the purchase trigger is wrong, timestamps do not align, transaction identifiers are reused, browser and server records are duplicated, consent state is missing, or nobody owns the integration after launch.

The more useful question is:

What is the smallest merchant-approved record that lets this destination perform a defined job—and how will the team prove that the record was received, processed and governed correctly?

That question forces five decisions before implementation:

  1. Purpose: Which optimization, reporting, lifecycle or diagnostic decision should the signal support?
  2. Source: Which Shopify or customer action is the underlying business event?
  3. Payload: Which event, value, identity and permission fields are actually necessary?
  4. Transport: Which browser, server, app-pixel, native-integration or API path will carry the record?
  5. Control: Who validates duplicates, late changes, consent changes, processing delays and future releases?

1 At Bat Media team practice

Define the genuine source event and intended destination action; record Primary/secondary status and the duplicate or count rule; inspect immediate firing or receipt; wait for the real destination read-back and normal reporting delay; and exclude incomplete historical periods from conversion-rate or CPA conclusions. This is a 1 At Bat Media team practice, not Travis McEwan's personal technical practice and not a universal platform standard.

Four records teams often mix together

The implementation becomes easier to govern when the team separates four record types.

Record type What it represents Common examples Control question
Commerce event Something happened at a defined time Checkout completed, order placed, refund, cancellation What exact source action triggers the event, and can it occur more than once?
Identity or match field A merchant-approved field proposed to associate an event with a person, browser, click or platform profile Email, phone, address, external ID, click ID, browser identifier Has the merchant documented why this field is necessary and approved for this purpose and destination?
Profile attribute A fact or property stored on a customer profile Location, preference, predicted attribute, customer type Who owns updates, deletion and accuracy?
Permission or subscription state An operational state recorded for a particular data use or communication channel Analytics setting, advertising or marketing setting, platform-recorded sale/sharing choice, email subscription, SMS subscription Which merchant-documented state governs this use, and how are later changes propagated?

A person can exist as a Klaviyo profile without being subscribed to email or SMS. A purchase event can be received by an advertising platform without proving the platform caused the order. In this framework, a hashed identity field is still governed data, not a reason to skip the merchant's privacy, security, contract or system-owner process.

Operating boundary: status is not legal permission

Treat analytics, advertising/marketing, platform-recorded sale/sharing and email/SMS states as distinct implementation inputs. Do not claim that a Shopify, Meta, Google or Klaviyo status proves a particular data flow is lawful, that hashing makes personal data anonymous, or that server-side transport bypasses the merchant's applicable requirements. If the purpose, destination, governing state, identity field or change-handling rule is absent, unclear or disputed, the 1 At Bat operating rule is to hold that field or signal until the responsible merchant owner resolves it.

The 1 At Bat Media signal-quality control model

This ten-step model is a proposed 1 At Bat Media team operating framework, not an independently validated industry standard or a claim that the agency has implemented every listed platform path.

  1. Define the decision and event. Name the business action, exact trigger and intended platform use before collecting data.
  2. Identify the commerce record. Specify which Shopify or order-system field records the event and which later changes may occur.
  3. Specify value and identity. Define value, currency, stable order or event ID, and only the merchant-approved match identifiers necessary for the stated purpose and destination.
  4. Record the merchant's governing operational state. Keep analytics, advertising/marketing, platform-recorded sale/sharing and email/SMS subscription states separate; do not treat the platform label as a legal conclusion.
  5. Document the transport path. Record whether the event travels through a Shopify app pixel, custom pixel, browser tag, server connection, native integration or API.
  6. Coordinate duplicate protection. Define what makes two records the same event and coordinate identifiers across relevant browser and server paths.
  7. Test destination receipt. Use the destination's current test or diagnostic surface to confirm that the expected payload arrived.
  8. Confirm processing. Distinguish data that was submitted or accepted from data that became processed, reportable or optimization-eligible.
  9. Plan for late changes. Define how refunds, cancellations, order edits, subscription changes, profile changes, retries and delayed events are handled.
  10. Assign ownership and regression QA. Keep one accountable owner, an implementation record, a rollback plan and a recheck rule for future releases.

1 At Bat Media team example

On 1 At Bat Media's own site, the team defined the genuine calendly.event_scheduled message as the booked-call boundary, mapped it to the Primary Google Ads action Calendly - Book Strategy Call with count method One, and kept Contact page loads secondary. In a later GTM destination setup, the team verified the base tag and SDK each loaded once in Tag Assistant but did not treat the destination's initial 0 recent events state as a failure before a real booking. Google Ads subsequently recorded one real Primary booked call, while pre-repair zeros remained excluded from CPA and conversion-rate conclusions.

This example demonstrates first-party event definition and measurement QA. It is not evidence of Shopify purchase-event implementation, Meta CAPI deduplication, Google enhanced conversions, Klaviyo API implementation, data-use permission, attribution quality or performance lift. Travis approved the work as business owner/requester; this passage is a team example, not a personal technical claim.

Source-to-destination decision matrix

This matrix is a planning aid, not a universal list of fields to transmit.

Signal class Minimum useful record Meta control Google Ads control Klaviyo control Release QA
Event definition Name, exact trigger, source and timestamp Coordinate the event meaning across Pixel and Conversions API paths Match the intended Google Ads conversion action and its tag or API source Attach one event to the correct metric and profile Fire the event from a known test action and inspect the expected destination record
Purchase value Stable order or transaction ID, value, currency and timestamp; line items only when required Send only merchant-approved purchase details necessary for the stated purpose and coordinate browser/server event identity Use transaction-specific value and currency when appropriate, plus a unique transaction ID Confirm the event value and actual Shopify-integration field behaviour Compare one test order across source and destinations; do not label it net or refund-adjusted revenue unless the implementation actually supports that definition
Identity or match data Only merchant-approved contact, external, click, browser or platform identifiers necessary for the stated purpose Apply current supported formatting and hashing rules where required Use enhanced-conversion inputs only under current product terms and the merchant's approved process Use a known profile identifier without assuming the profile is marketable Validate presence, formatting and diagnostics without exposing personal data in public examples
Operational state Keep analytics, advertising/marketing, platform-recorded sale/sharing, email and SMS states separate Do not treat server transport as a bypass of the merchant's requirements Use consent mode to communicate state; do not describe it as a consent banner or proof of permission Keep profile existence, event activity and channel subscription separate Test approved, denied, changed and unavailable-state scenarios defined by the merchant; hold when the required state is unclear
Browser/server transport Source path, event ID, retry behaviour and destination Coordinate event name and event ID for the same browser/server action Document which tag, integration or API supplies the conversion and how duplicates are controlled Record native Shopify sync, onsite events and API jobs separately Confirm that one source event does not create unintended duplicate destination records
Processing state Submitted, received, processed, diagnostic status and reporting date Use currently accessible official test tools; do not invent a universal quality threshold Separate immediate request inspection from later account diagnostics A 202 response means validated and submitted for processing; it is not proof of recording, completed processing or reportability Define a destination-specific waiting and read-back rule before classifying a failure
Late update Refund, cancellation, order edit, retry, profile update or consent change Verify the current integration's support before promising update behaviour Use stable transaction identity and current product rules for eligible adjustments Test sync direction and timing rather than assuming symmetrical updates Run the real late-update path and record the result

Shopify: govern the event layer before choosing destinations

Shopify's Web Pixels API and pixels manager provide a controlled layer for customer events. Shopify's current documentation separates analytics, marketing, preferences and data-sale permission states, and explains that app-pixel callbacks can depend on the permissions declared by the app and the customer's consent state. See Shopify's web-pixel overview, Customer Privacy API and pixel privacy documentation.

The checkout_completed event can expose checkout, order, transaction, value and currency information, but the available fields depend on the checkout architecture and access to protected customer data. Shopify says the event normally fires once per checkout, but a post-purchase flow can move that trigger to the first upsell page, and the event may not fire if the expected page fails to load. A completed checkout is not automatically the same as settled, net or refund-adjusted revenue. See Shopify's checkout_completed reference.

Before a Shopify event is released to another platform, document:

  • the exact customer action that triggers it;
  • whether the event can replay or arrive late;
  • the time-zone basis for its timestamp;
  • how value and currency are defined;
  • the stable event, order or transaction identifier;
  • the applicable consent or permission dependency;
  • every transport path that can send it; and
  • the owner of future checkout, theme, app and consent-management changes.

Do not assume that using a native integration removes the need for QA. Shopify specifically warns about duplicate or missing events during pixel migrations and recommends testing consent-banner behaviour. See Shopify's pixel-migration guidance.

Documentation boundary — Shopify

This section summarizes the linked Shopify documentation and the guide's conservative team framework. It does not claim that Travis McEwan or 1 At Bat Media personally implemented this Shopify event-layer pattern for a merchant. Validate the current store architecture and documentation before operational use.

Meta: coordinate browser and server events

Meta's official Business SDK materials support server-side delivery of web, app and offline events through Conversions API. A server event can include event name and time, customer information approved by the merchant for the stated purpose, value and currency, the event-source URL and the action source. See the official Meta Business SDK Conversions API overview.

For the same customer action sent through browser and server paths, Meta's current SDK uses event_id with event_name as part of duplicate-event identification. Enabling Pixel and Conversions API does not, by itself, prove that duplicates are prevented. The team must coordinate event identity and test the implementation. See Meta's official ServerEvent source.

The SDK also supports test_event_code for Events Manager Test Events. A successful test is evidence of test-event receipt, not evidence of attribution, incrementality, optimization quality or business lift. See Meta's official EventRequest source.

As a conservative operating boundary—not a claim established by the SDK—do not describe Conversions API as cookie-proof, lossless, a substitute for the merchant's applicable data-use process or guaranteed to improve CAC or ROAS. This guide does not prescribe a universal Event Match Quality threshold because no current accessible official source was used to justify one.

Documentation boundary — Meta

This section summarizes the linked Meta SDK materials. It does not claim that Travis McEwan or 1 At Bat Media personally implemented browser/server purchase deduplication for a merchant. The owned-site Calendly/GTM example above is not evidence of Meta CAPI implementation.

Google says enhanced conversions supplements existing conversion measurement with hashed first-party user-provided data and uses conditional language: it can improve measurement. It is not a guarantee of recovered conversions, better bidding or a performance lift. See Google's enhanced-conversions overview.

Google's current implementation supports user-provided data from website tags, Data Manager and API connections under a unified enhanced-conversions setting. Because the interface and migration path can change, this guide defines decisions and QA controls rather than freezing one sequence of interface clicks. See Google's 2026 enhanced-conversions update.

When purchase value is the intended optimization input, use the transaction-specific value and currency defined by the business. A unique dynamic transaction ID can reduce duplicate purchase conversions; a static or reused ID can suppress legitimate records. See Google's guidance on conversion values and transaction IDs.

Google consent mode communicates consent state to Google tags. It is not a consent-management platform and does not obtain customer consent. See Google's consent-mode overview.

Documentation boundary — Google Ads

This section summarizes the linked Google documentation. It does not claim that Travis McEwan or 1 At Bat Media personally implemented enhanced-conversion inputs or Shopify purchase transaction-ID measurement for a merchant. Do not describe modeled conversions as observed Shopify orders.

Klaviyo: separate events, profiles and channel permission

Klaviyo defines an event as a timestamped action associated with one metric and one profile. Creating an event requires a known profile identifier and a metric name. Event properties and profile properties are separate records. See Klaviyo's Events API overview.

Klaviyo's Create Event endpoint returns 202 after a request is validated and submitted for processing. That is not proof of recording, completed processing or reportability. Klaviyo also warns that events using test-domain email addresses can return 202 and then be silently dropped. See Klaviyo's Create Event reference and Events API overview.

Klaviyo's current Events API uses a client-supplied unique_id for idempotency. Reusing the same identifier for the same profile and metric discards the later event as a duplicate; omitting it can also cause same-second events to share a default identifier. A backfill flag can record historical events without re-triggering flows. These are implementation controls, not evidence that the event was attributed correctly or produced revenue.

A profile is also not automatically an email or SMS subscriber. Profile properties, event activity and subscription states must remain separate in the operating record. See Klaviyo's Profiles API overview.

The Shopify integration can sync profiles, orders and consent information, with optional onsite behavioural events. The actual fields and timing depend on the store's configuration, and Shopify-to-Klaviyo and Klaviyo-to-Shopify behaviour is not symmetrical for every update, deletion or suppression. See Klaviyo's Shopify integration guide, Shopify data reference and Klaviyo-to-Shopify sync guidance.

Documentation boundary — Klaviyo

This section summarizes the linked Klaviyo documentation. It does not claim that Travis McEwan or 1 At Bat Media personally implemented the event/profile/subscription or sync patterns described here. No first-hand accepted-but-unprocessed or profile/subscription example is asserted.

Build one minimum viable signal record

Before implementation, put every approved signal into one shared control record.

Field Required entry
Decision supported Exact optimization, reporting, lifecycle or diagnostic decision
Source event Shopify or customer action and exact trigger
Source owner Accountable ecommerce, analytics, development or business role
Destination Meta, Google Ads, Klaviyo or another approved system
Event or metric name Exact destination event or metric
Event time Timestamp and time-zone basis
Value and currency Definition, units and fallback rule
Stable identifier Order, transaction or event identifier and uniqueness rule
Identity fields Exact merchant-approved fields, purpose, formatting/hashing requirement and owner
Operational-state dependency Required analytics, advertising/marketing, platform-recorded sale/sharing or subscription state; hold if absent, unclear or disputed
Transport Browser, server, app pixel, native integration or API
Duplicate control Coordinated identifier and downstream rule
Receipt check Test event, tag helper, request inspection or API confirmation method
Processing check Later diagnostic or read-back and expected reporting delay
Late update Refund, cancellation, retry, replay, suppression or consent-change handling
Change record Release time, owner, approver, rollback and next regression check

This record is useful only if the team keeps it current. Assign one accountable owner for the whole implementation and named supporting owners for Shopify, paid media, lifecycle, analytics/development and privacy decisions.

Proposed 1 At Bat Media ownership boundary

Use one accountable implementation owner, named supporting owners, a release record, a rollback path and a scheduled regression check. The merchant retains responsibility for its development, privacy, security, contract and platform decisions; this framework does not imply that 1 At Bat Media always owns those functions.

Diagnose the signal before diagnosing performance

Symptom Source check Destination check What not to conclude
Purchase count changes suddenly Shopify release, checkout flow, event trigger, retries and duplicate path Test events, tag/request history and later diagnostics A campaign caused the change
Purchase value is missing or uniform Source value/currency definition and fallback Destination parameter receipt and conversion-action setting ROAS is accurate or inaccurate from one surface alone
Browser and server totals diverge Event-name and event-ID coordination, retry behaviour Duplicate diagnostics and test-event records Every difference is loss or duplication
Enhanced-conversion diagnostics are absent immediately after launch Tag firing, merchant-approved user-provided data and configuration Later Google Ads diagnostics after the documented reporting delay The implementation failed immediately
Klaviyo returns 202 but no event appears yet Request structure, profile identifier, metric and timestamp Processing delay, event lookup and current API diagnostics The event is already fully processed—or permanently missing
Subscriber totals differ across systems Source consent record, channel and update time Klaviyo profile and channel-subscription state A profile is automatically marketable
Revenue differs across platforms Confirm event/value integrity only Use each platform's defined reporting role The signal-quality guide should reconcile attribution totals

For the full reporting hierarchy, use Why Shopify, Meta, Google Ads, GA4 and Klaviyo Revenue Numbers Don't Match. This guide stops at the quality and governance of the input signal.

What good signals do not prove

  • Receipt does not prove processing.
  • Processing does not prove attribution.
  • Attribution does not prove incrementality.
  • A more complete match does not prove profitability.
  • More measured conversions do not necessarily mean more orders occurred.
  • Platform diagnostics do not replace Shopify/order and finance reconciliation.
  • Better inputs do not guarantee lower CAC, higher conversion rate, better ROAS or more revenue.
  • Hashing does not remove privacy, security, disclosure, consent or contractual obligations.

Those boundaries matter because signal quality is a prerequisite for better decisions, not a shortcut to causal proof.

Who this guide is—and is not—for

Good fit

  • An established Shopify-led brand actively using Meta Ads, Google Ads or Klaviyo.
  • A team with overlapping browser, server, native-app or API connections and unclear ownership.
  • A business changing checkout, consent, customer-event or integration architecture.
  • A team that can involve ecommerce, analytics/development, paid-media, retention and privacy owners.
  • A brand that wants a testable control record before relying on platform diagnostics.

Not a fit for a generic implementation checklist

  • A brand asking for a universal list of every personal-data field it should share.
  • A team that has not defined its business decisions, conversion actions or permission requirements.
  • A business seeking legal, privacy or security advice for a particular jurisdiction or implementation.
  • A team expecting signal implementation to prove causation or guarantee a performance lift.
  • A pre-revenue business without stable orders, events or accountable implementation ownership.

Operating boundary: hold rather than infer

This guide does not say which data a particular merchant is legally permitted to collect or send. It provides an internal workflow safeguard: state the purpose, minimize the proposed record to what the merchant has approved for that purpose, keep channel and data-use states distinct, document the destination and change path, and hold the signal when the responsible owner cannot establish the required state. This operating boundary is not a jurisdiction-specific compliance conclusion.

The next operating step

Do not start by adding another tag or connection. Choose one high-value commerce event, complete the minimum viable signal record, test each approved path, record immediate receipt and delayed processing checks, then assign the next regression date.

If the team cannot name the event definition, merchant-approved payload, duplicate rule, processing check and accountable owner, the signal is not ready to support a scaling decision.

How 1 At Bat Media can help

1 At Bat Media helps established ecommerce brands connect paid media, Shopify conversion, lifecycle marketing and measurement decisions. If your team needs an implementation and ownership review, we can assess the current signal map and identify the smallest high-confidence next step. No performance outcome is promised.