TikTok's customer_type and attribution_share Parameters on Shopify

TL;DR

TikTok's Events API parameters page carries two optional fields that were not there a year ago, customer_type and attribution_share; the page was last updated in March 2026 [1]. They are not equally useful to a Shopify merchant. customer_type labels each purchase as new or returning, which your store can answer from the buyer's order history. attribution_share is a credit split you would have to compute yourself, and a Shopify order contains nothing that produces it. WeltPixel Conversion Tracking sends customer_type to TikTok on the server-side purchase event, on the Plus plan, for identified buyers. It sends no attribution_share at all, and no app should pretend otherwise. Meanwhile the two parameters TikTok actually requires for ROAS reporting, value and currency [1], are the ones most likely to be silently wrong on a multi-currency store.

Key Takeaways

• customer_type and attribution_share are both optional on TikTok's Events API, and neither was on the parameters page a year ago; the page was last updated in March 2026 [1]. Neither is needed for basic conversion tracking.
• customer_type carries new or returning. WeltPixel Conversion Tracking derives it from the buyer's Shopify order history at the time of the order: bought before means returning, first purchase means new.
• Guest checkouts get no label. There is no order history to read, so the app omits the parameter.
• The label rides the purchase event only. Browse events and refunds do not carry it, on TikTok or anywhere else.
• attribution_share expresses a share of conversion credit, not a fact about the buyer. WeltPixel Conversion Tracking does not send it, and deriving one from a Shopify order would be invention.
• value is required for ROAS and value-based optimization, currency is required for ROAS [1]. Get those right before touching optional parameters.
• The same new-versus-returning label goes to GA4, Meta, TikTok and Google Ads from that one purchase, with nothing to configure per platform.

What the two parameters do

customer_type is a string on the event that says whether the person who bought is new to your store or has bought before. TikTok accepts it as an optional field alongside the rest of the purchase payload [1]. Nothing in TikTok's system computes it for you. If it is not in the payload, TikTok has no view on whether this buyer is a repeat customer.

attribution_share is a different kind of field. It expresses a share of the conversion's credit rather than a property of the buyer, so unlike customer_type there is no order field to read it off. Whatever share you send would come from your own attribution model. Treat that as our reading of an optional parameter rather than an instruction from TikTok, which documents the field without telling anyone they need it.

That difference decides which one you can act on this week. One is a lookup against data Shopify already holds. The other is a modeling exercise most stores have not done, and sending a made-up number into an ads platform's optimization loop is worse than sending nothing.

Which parameter can a Shopify store actually fill in?

customer_type, and the derivation is boring in a good way. When an order comes in, the app reads the buyer's Shopify order history at the time of the order: bought before means returning, first purchase means new. A guest checkout has no customer record to read, so no label is attached. Silence there is correct behavior.

This is a purchase-time label. It is attached to the server-side purchase event and to nothing else. Browse events do not carry it. The label is attached where the order history is read, which is the server-side purchase. Refunds do not carry it either, because the refund payload does not take it. Our deeper piece on new versus returning customer tracking on Shopify walks through what each platform does with the label once it arrives, including Google's new customer acquisition bidding, which only reads the label on Purchase-category conversion actions [4].

attribution_share stays empty on a WeltPixel store. Zero events carry it. If your reporting genuinely needs fractional credit sent to TikTok, that has to come from your own attribution model through your own Events API integration, and you should be able to state where the number comes from before you send the first one.

How does the label reach TikTok?

TikTok events from a WeltPixel Conversion Tracking store are delivered server-side through the Events API. The one exception is the page view, which is the only TikTok event that can fire from the browser. So the purchase carrying customer_type is a server event, sent from Shopify's order webhook, independent of whether the buyer's browser survived checkout with an ad blocker running.

Requirements, in the order they bite:

TikTok is one of four destinations for this label. The same order sends it to GA4 as an event parameter, to Meta, and to Google Ads on the uploaded conversion. Reddit, Pinterest, OpenAI Ads and Klaviyo receive no customer_type from the app.

Why is customer_type missing from your TikTok events?

Work down this list before opening a support ticket.

1. Plan. The free plan is GA4-only, so no TikTok event exists to carry the parameter. Check the plan first.
2. Guest checkout. Look at the order in Shopify. No customer account attached means no label, by design.
3. Wrong event. Check a purchase, not a page view or an add to cart. The browse funnel never carries it.
4. A refund. Refund events take no customer type on any platform.
5. Looking in the wrong place. In TikTok Events Manager, open your pixel, then Test Events, and inspect the full payload of a test purchase rather than the summary row.

Number two is the one that surprises people. On a store where most buyers check out as guests, a large share of purchases will legitimately arrive unlabeled, and TikTok's reporting will show a smaller new-versus-returning split than your Shopify reports do. That gap is a checkout behavior fact, not a tracking fault.

The parameters that matter more than either of these

TikTok is explicit about what it needs: value is required for ROAS reporting and value-based optimization, and currency is required for ROAS [1]. Both parameters are on every purchase WeltPixel Conversion Tracking sends, taken from the order total including tax and shipping, in your store's base currency, with the currency code matched to the amount.

The matched pair is the part to check. On a multi-currency store, a mismatch between the amount and the currency code is what produces conversion values that look wrong by a factor of the exchange rate, and we covered that failure mode in detail in why ad platforms show the wrong conversion value on multi-currency stores. Fix that before you spend an afternoon on optional fields.

One more piece of context on TikTok's own recommendations: it advises running the Pixel and the Events API together with deduplication, and its dedup window is 48 hours, with the first arrival winning [3]. On a WeltPixel store the ecommerce events are server-delivered, so there is no browser twin of the purchase to deduplicate against. The page view is the one event that exists on both sides, and it carries a shared event ID for exactly that reason. Our event deduplication guide covers the general mechanism.

Verifying it in TikTok Events Manager

1. Place a test purchase from a customer account that has bought from you before.
2. In Events Manager, open your pixel and go to Test Events with your test event code set in the app's TikTok settings.
3. Find the purchase event. The app sends TikTok's PlaceAnOrder and Purchase, both on by default, so you may see two rows for one order; open either one's full payload.
4. Confirm customer_type reads returning, and that value and currency match the order total in your store's base currency.
5. Repeat with a guest checkout. The absence of the parameter there is the expected result.

TikTok's standard event set is 20 events and did not change in the last year [2]. If the setup itself is new, our TikTok Events API setup and verification guide covers the credential steps and the first-week checks.

FAQ

Does WeltPixel Conversion Tracking send attribution_share to TikTok?

No. The app sends no attribution_share value on any event. TikTok lists the parameter as optional [1], and nothing in a Shopify order produces the credit share it expresses, so the app leaves it out.

Which plan do I need for customer_type?

The $39/mo Plus plan. The free plan covers GA4 tracking only and sends no TikTok events, so the parameter is out of reach there regardless of setup.

How does the app decide new versus returning?

From the buyer's Shopify order history at the time of the order: bought before means returning, first purchase means new. Guest checkouts carry no history and get no label.

Do my browse events carry customer_type too?

No. It travels on the purchase event only, on TikTok and on the other platforms that receive it. Browse events do not carry it. The label is attached where the order history is read, which is the server-side purchase.

Will this fix a mismatch between TikTok's reported conversions and Shopify's orders?

No, and it is not meant to. customer_type is a segmentation label, not an attribution fix. Count differences come from attribution windows, dedup and identity matching, which are separate problems from what this parameter carries.

If you run TikTok ads on Shopify and want purchases delivered server-side with the new-versus-returning label attached, install WeltPixel Conversion Tracking, connect TikTok, and place one test order from a repeat customer to confirm the payload.

Sources

1. TikTok Ads Manager Help Center, Events API parameters reference, https://ads.tiktok.com/help/article/events-api-2-0-parameters, page last updated March 2026, accessed August 24, 2026
2. TikTok Ads Manager Help Center, Standard events reference, accessed August 24, 2026
3. TikTok Ads Manager Help Center, Pixel and Events API deduplication, accessed August 24, 2026
4. Google Ads Help, About new customer acquisition goals, support.google.com/google-ads/answer/12077475, accessed August 24, 2026