Attribution
Last-touch credit, the fields captured at checkout, and why the Order keeps the record
Attribution answers one question: where did this buyer come from? Ulsav uses last touch. The source credited for an Order is the one captured most recently before the Order was confirmed, and it is stored on the Order itself. This page explains what gets captured, how it is cleaned, and what the model cannot tell you.
Model
Last touch
One source per Order
Stored on
The Order
Not only in analytics
Captured from
UTM, referrer, landing host
Also stored
First-touch fields
Preserved, not yet used
Field limit
256 characters
Missing data
Recorded as direct
What is captured
At checkout, Ulsav takes the buyer's current attribution and stores it on the Order as a snapshot. The snapshot can hold:
| Field | Example |
|---|---|
| Source | |
| Medium | social |
| Campaign | monsoon-early-bird |
| Term | running-shoes |
| Content | story-ad-2 |
| Referrer host | l.instagram.com |
| Landing host | ulsav.com |
| Click ID and type | a provider click identifier |
| Captured at | A timestamp |
| First source, medium, campaign, referrer, landing | The earliest captured values |
The first-touch fields are preserved for a future first-touch or multi-touch model. Nothing in the product reads them today.
How the values are cleaned
A client can send anything, so the server normalizes before storing.
- Text is trimmed and stripped of control characters.
- Each text field is capped at 256 characters.
- Hosts are reduced to a bare hostname.
- Unknown fields are dropped.
- An empty or unusable payload becomes an empty object.
An empty object is how Ulsav records direct traffic. It never guesses a source.
Where the values come from
The beacon on public pages captures the UTM source, medium, and campaign from the page URL, plus the referrer host and the landing host. Those are the fields a public page can see.
Term, content, and click identifiers are stored when a checkout sends them. A public page visit alone does not produce them.
Source and medium are classified as follows:
| Situation | Source | Medium |
|---|---|---|
| A UTM source is present | The UTM source | The UTM medium, or referral |
| No UTM, referrer is Google, Bing, DuckDuckGo, Yahoo | The host | search |
| No UTM, referrer is Facebook, Instagram, X, LinkedIn, YouTube | The host | social |
| No UTM, referrer is a Ulsav host | The host | internal |
| No UTM, another referrer | The host | referral |
| No referrer at all | direct | none |
How the dashboard labels it
The source breakup turns a raw value into a name a person recognizes. Instagram, Meta, YouTube, Google, LinkedIn, X, WhatsApp, Telegram, Email, and Direct are recognized by substring.
Anything else keeps its own value, title-cased. A landing host on a Ulsav domain becomes Ulsav Market or Portal. An Order with no source and no landing host becomes Direct.
That means a campaign with a typo appears as its own bucket, not as Direct. Check the UTM spelling before blaming the model.
The Order is the durable record
Attribution lives on the Order because the Order is what you export, invoice, and reconcile. The attribution report and the Orders list therefore agree by construction.
A later campaign change cannot rewrite an Order's source. Attribution follows the same snapshot rule as price, tax, and fee.
Snapshot, not a live join
Editing a UTM on a live page changes future Orders only. Orders already confirmed keep the source they were captured with.
Identity stays inside the Organization
Accounts are global, but organizer-facing reads are not.
A Visitor identifier can stitch to an Account on sign-in, and an Account can stitch to a Participant through domain records. An organizer still sees returning behaviour only inside their own Events. The same person attending two Organizations appears independently to each.
The visitor identifier is browser storage, not a login. When Do Not Track is on, no visitor identifier is sent, so returning-visitor behaviour cannot be attributed in that browser.
Pixels
An Organization can store public identifiers for GA4, Google Tag Manager, Meta, and TikTok, plus a consent-required flag. Those settings exist.
No public page loads them today. First-party Facts are the only measurement that runs, so a stored pixel ID has no effect yet.
What last touch cannot answer
- It credits the final source, not the first. A newsletter that introduced a buyer who returned through a search ad a week later gets no credit.
- It cannot split credit across several touches. There is no multi-touch model.
- It cannot see a purchase that arrives with no referrer and no UTM. That Order is Direct.
- It cannot see inside an in-app browser that strips the referrer. The landing host is often the only clue left.
- It cannot tell you which creative worked when the campaign value is the only thing shared across several ads.
That limitation is deliberate. One model, computed one way, stored on the record you already trust.
Common failure paths
- No traffic, all direct. The beacon is blocked, the page is opened from a saved link, or the campaign links lack UTM parameters.
- Everything is one host. The referrer is present but the UTM parameters are missing, so the host becomes the source.
- A source you do not recognize. The raw UTM source is shown title-cased because it matches no known name.
- A report and a dashboard disagree on totals. The dashboard groups by a friendly label; the report groups by raw source and medium. Two raw values can share one friendly label.
Related
- Metrics — how the traffic and commerce facts are built
- Reports — the Attribution report
- Orders — where the snapshot lives
- Event visibility — which surfaces are public