# Referral exclusions: your own domains and the payment gateway

Two referrers are never acquisition: your own domains, and the payment gateway that sends the customer back after they pay. AdPix sets both aside so the sale is credited to the campaign that actually earned it — not to the bank.

## Two problems that look alike

Every visit has a referrer: the page the browser says the user came from. AdPix uses it to work out the acquisition channel. There are two cases where that referrer is not acquisition at all, and if you leave them alone they steal the credit for a sale from the campaign.

| Problem | What happens | Where it is configured |
| --- | --- | --- |
| A referral from your own domain | Moving from `shop.example.com` to `example.com` opens a new session sourced "Referral / shop.example.com" | Admin → **Data streams** → the stream → **Configure your domains** |
| The return from a payment gateway | The customer pays, the bank sends them back, and the visit that converts is sourced `sep.shaparak.ir` | A built-in list — nothing to configure; extra hosts via the API |

Both get the same treatment: instead of counting as fresh acquisition, that touch is demoted to Direct — `(direct)` / `(none)` — and the real earlier touch stays in place. But they are configured in two different places and each covers different ground.

## Referrals from your own domains

When one business spans several domains or subdomains — the shop, the blog, the customer panel, a checkout page — every hop between them is a referral as far as the browser is concerned. Without an exclusion, your own site becomes the biggest "referrer" in Traffic acquisition and every visitor is re-acquired halfway through their own journey.

AdPix already treats these hosts as internal:

- the domain of each web stream on the property (the one you entered when you created the stream);
- the property's primary domain, which is itself derived from the first web stream's domain;
- every condition you added to that stream's cross-domain linking configuration.

A referrer matching any of those is not acquisition. On top of that, whenever the referrer's root domain equals the current page's root domain it counts as internal with no configuration at all — so navigation between subdomains of one domain is correct from day one.

### Adding your other domains

1. Open **Admin** in the console.
2. Under **Property settings**, select **Data streams** and open your web stream.
3. Select **Configure your domains** to open **Cross-domain Linking Configuration**.
4. Use **+ Add condition** to add every other domain that carries this same tag.
5. Select **Save**.

There are five match types. For your own domains **Exactly matches** is almost always the right one:

| Match type | What it matches |
| --- | --- |
| **Exactly matches** | the host itself, any of its subdomains, or any host on the same root domain |
| **Contains** | the host contains this string |
| **Begins with** | the host starts with this string |
| **Ends with** | the host ends with this string |
| **Matches RegEx** | the host matches this regular expression |

> **The same list also turns on cross-domain measurement**
>
> This list does two jobs at once: it tells the tag to carry the visitor ID across a hop between your domains (so one person is not counted as two), and it tells the server not to treat that referral as acquisition. That is why it is one card in the console rather than two. The linking side is covered in [Cross-domain and subdomain measurement](analytics/collect/cross-domain-and-subdomain).

## The return from a payment gateway

This is the one that hits revenue directly. The customer clicks a Google ad, picks a product, is sent to the bank's gateway, pays, and the bank returns them to your "payment successful" page. The browser reports that return as a fresh referral from `sep.shaparak.ir` — and the last touch of the very visit that converts was being overwritten with it.

For anyone setting budget the consequence is severe: the ad channel looks unprofitable, an imaginary "referral" channel looks like the star performer, and the budget decision follows the wrong number.

AdPix carries a built-in list of payment processors. It is keyed by **function**, not geography — Iran's Shaparak switch sits alongside Stripe and PayPal and nothing in it is specific to one market:

| Group | Root domains |
| --- | --- |
| Iran | `shaparak.ir` · `zarinpal.com` · `nextpay.org` · `idpay.ir` · `payping.ir` · `pay.ir` · `zibal.ir` · `behpardakht.com` · `vandar.io` · `jibit.ir` · `novinpal.com` |
| Global | `stripe.com` · `checkout.stripe.com` · `paypal.com` · `paypalobjects.com` · `adyen.com` · `checkout.com` · `squareup.com` · `square.com` · `razorpay.com` · `payu.com` · `braintreegateway.com` · `2checkout.com` · `worldpay.com` · `klarna.com` · `mollie.com` · `authorize.net` · `verifone.com` · `ecpay.com.tw` |

Matching is on the root domain and covers sub-hosts, so the single entry `shaparak.ir` covers every bank switch behind it — `sep`, `pep`, `sadad`, `asan` and the rest.

### Where the real campaign comes back from

Demoting the gateway is not enough on its own: throw the referral away and the conversion is left with no campaign at all and falls into Direct, which is just another way of losing the credit.

So AdPix keeps each anonymous visitor's last touch server-side, and restores it whenever the current touch carries no real acquisition signal. The rule is short:

- **First touch**: first write wins, and is never replaced.
- **Last touch**: last write wins, but only for a touch that genuinely signals acquisition — a campaign or an ad click ID. Direct traffic, an own-domain referral and a gateway return all fail that test, so none of them can erase the stored campaign.

In practice: a purchase that began with a Google ad click and came back through Shaparak sits under that Google campaign in [Attribution](analytics/reports/attribution), and no longer opens a new "Referral" session for the bank in [Traffic acquisition](analytics/reports/traffic-acquisition).

## Adding your own hosts to the exclusion list

If you use a gateway or payment intermediary that is not in the built-in list — or a partner who returns the user to you after an identity check or a signed contract — you can add its host to the property's own list. It is unioned on top of the built-in one.

There is no console screen for this yet; it is API-only, and like the rest of Fraud Protection it is gated on the plan.

| Call | What it does |
| --- | --- |
| `GET /api/v1/integrity/referral-exclusion?site=<property_id>` | list this property's excluded hosts |
| `POST /api/v1/integrity/referral-exclusion?site=<property_id>` | add or update one host — body `{"host":"…","note":"…"}` |
| `DELETE /api/v1/integrity/referral-exclusion/{host}?site=<property_id>` | remove one host |

Reading the list is open to any viewer of the property; adding and removing require edit access and both are written to the audit log. The host is stored lowercased and trimmed, and like the built-in list it matches sub-hosts too.

## The same list keeps your fraud report clean

A payment-gateway return is the opposite of fraud: it is a session that paid you money. Its statistical shape is odd all the same — a source that appears out of nowhere, single-page, with a uniform pattern — and an unguided detection engine reads that as an anomaly.

That is why Fraud Protection reads the same list as an allowlist: a source whose host matches a built-in gateway or one of the property's own exclusions always stays **Clean** and is never flagged. Alongside it, the business's own identifiers — the property's primary domain, the property name and the organization name — get the same protection automatically, so your own brand and internal traffic is not reported as fraud.

> **This does not rewrite the past**
>
> Referral exclusions are applied at **collection** time, not when a report is read. A new host takes effect on subsequent events within about a minute, but events already stored keep the attribution they were written with. That is the exact opposite of channel definitions, which are applied on read and reclassify your whole history the moment you edit them. To correct historical data — months of sales credited to a gateway, say — contact support; repairing the past is a platform-side operation.

## How to confirm it works

1. Open a test link carrying a known `utm_source` and `utm_campaign`, and complete a real or test purchase end to end.
2. In **Traffic acquisition**, set the range to today and look for the gateway host as a source — no new row should be created for it.
3. In **Attribution**, find that conversion; it should sit under the campaign you used in step one.
4. If you still see the gateway as a source, take the exact host from the report and check whether its root domain is in the built-in list; if it is not, add it to the property's exclusion list.

If nearly all of your traffic has fallen into Direct — not just conversions — the cause is somewhere else, and [Attribution](analytics/reports/attribution) is a better place to start looking.

## Frequently asked questions

### Why are my purchases sitting under "Referral / sep.shaparak.ir"?

Because the return from the payment gateway looked like a fresh referral to the browser and was written over the last touch — so the visit that converts handed its credit to the bank. AdPix now demotes a gateway return at collection time and restores the real campaign from that visitor's durable last touch. Rows already collected keep the attribution they were written with.

### Our payment gateway is not in the built-in list. What do I do?

Add its host to the property's own exclusion list. That list is API-only today — POST to /api/v1/integrity/referral-exclusion with a host in the body — and it is gated on the Fraud Protection feature. Matching covers sub-hosts, so adding the root domain is enough.

### Does excluding a referrer delete its traffic?

No. No event is dropped and no visitor disappears. The only thing that changes is that the return no longer counts as a fresh acquisition, so it cannot wipe out the campaign that came before it.

### How is this different from channel definitions?

Channel definitions are applied on read, so editing them reclassifies your whole history instantly. Referral exclusions are applied at collection time and do not touch events already stored — they only shape traffic collected after the change.

## Related

- [Cross-domain and subdomain measurement](https://docs.adpix.io/en/analytics/collect/cross-domain-and-subdomain/)
- [Attribution](https://docs.adpix.io/en/analytics/reports/attribution/)
- [Traffic acquisition](https://docs.adpix.io/en/analytics/reports/traffic-acquisition/)
- [Sensitivity and false positives](https://docs.adpix.io/en/analytics/fraud/sensitivity-and-false-positives/)

---

[Docs](https://docs.adpix.io/en/analytics/fraud/referral-exclusions/) · AdPix