Back to blog
Attribution3 min read

Why Tabby and Tamara make your paid channels look weak

Instalment checkout sends the shopper off your store and back. Most tools read the return as a new direct visit, so the ad that produced the sale gets no credit.
Instalment checkout sends the shopper off your store and back. Most tools read the return as a new direct visit, so the ad that produced the sale gets no credit.

A shopper taps your Snapchat ad, lands on your store, leaves to Tabby to complete payment, and comes back. The order is recorded as direct.

If a large share of your customers pay in instalments, that single mechanic makes every paid channel in your account look weaker than it is.

What happens the moment the shopper leaves

Checkout hands the shopper to an external domain. When they return, most setups see a fresh visit whose referrer is the gateway domain, or no referrer at all.

The system treats the first session as finished and starts a new one. The order attaches to the new session, so it's credited to the last visible source instead of the real one.

Nothing errors and no event is missing. There's an order written against the wrong source, and every report built on top of it inherits that.

How it shows up on your dashboard

  • The direct bucket grows month after month while nothing changed in your SEO or brand search
  • Paid channels read weaker than they are, and instalment-heavy products are hit hardest
  • You pause a working campaign, sales drop two weeks later, and nobody connects the two

The tell is the correlation: the higher the share of instalment payments in your store, the larger the gap.

Direct isn't a channel to begin with. It's the bucket for every visit the system couldn't name. That matters because it's the one line in your report you can't act on. You can't spend more on direct, optimise direct, or brief an agency on direct. So a growing direct share doesn't just distort the numbers, it moves budget into a column where no decision is possible.

An example with hypothetical figures

A store doing 480 orders a month, with 60% of them paid in instalments, so 288 orders pass through an external gateway.

Before gateways are treated as pass-through:

  • 288 orders sourced to direct or to the gateway name
  • plus 72 genuinely direct orders
  • 360 orders with no known source, which is 75% of the month

Afterwards those 288 return to their real sources. Say 150 Snapchat, 90 Meta, 48 Google.

Here's what that does to one budget decision, taking Snapchat at a 200 SAR average order:

Recorded ordersAttributed revenueSpendROAS
Before102,000 SAR5,000 SAR0.4×
After16032,000 SAR5,000 SAR6.4×

Hypothetical figures, meant to size the decision rather than describe a real store.

Nothing changed in the campaign. What changed is where the order was written.

Treat payment gateways as pass-through

The principle goes beyond payments: any destination a customer passes through and returns from should be treated as a transit step, not a new source.

Applied properly, gateway domains are classified as pass-through. The session stays attributed to its original source, and the shopper re-enters the same journey instead of starting a new one. Flowfy covers Tabby, Tamara, PayPal, Stripe and myshopify as pass-through domains.

This fix is unusually cheap. Most measurement improvements need history: a model to train, a month of data to accumulate, a volume threshold to clear. This one needs none of that, because it's a classification rule. Install it today and the next order through a gateway is written against its real source.

How to check whether it's happening to you

  1. Look at your direct share over the last six months. Is it growing?
  2. Compare it against your instalment payment share over the same period.
  3. Ask whether SEO, brand search and email actually grew enough to explain the rise.

If direct is climbing while brand demand is flat and instalment payments are rising, you're most likely looking at gateway attribution loss rather than genuine direct traffic.

Common questions

Does this affect card payments too? Any redirect off-site and back can break a session, including 3-D Secure checks. Instalment providers are simply the most common case in this market.

Can I fix it with UTM parameters? Not reliably. The return leg isn't a link you control, so there's nothing to tag. The classification has to happen where sessions are stitched together.

Will my historical data be corrected? No. Attribution is applied as orders arrive, and past orders keep the source they were written with. That's one more reason to fix it before a season rather than after.

Does it work the same on Zid? Yes. The break is in the checkout redirect, not in the store platform.

Before you move any budget