docs
Open the app →

What UTMCAP does

UTMCAP records where a click came from, where it went, and whether it turned into money — across ad platforms that let you redirect and ones that do not.

A tracker answers one question: for every click you paid for, what happened next?

That sounds simple until the click leaves your control. It lands on a page you host, presses a button that leads somewhere else, and converts on a third party's server minutes or days later. Nothing in that chain knows about the others unless something threads them together.

UTMCAP is that thread. It issues an id at the moment of the click, keeps it through the landing page, carries it to the offer, and matches it back when the conversion is reported.

#How a click travels

Visitor clickson the platform you boughtTracking URLrecords it, issues the id302 onwardthe id rides on ?cid=Landing pagethe tag keeps the id/out/<click id>what the button becomesOffercarrying your click idConversionon the network’s serverPostbackthey call back with the idJoined upto the click it came fromthen, on your pageminutes or days later
One click, end to end. The id issued at the first hop is what lets a conversion on somebody else’s server, days later, name the ad that paid for it.

Not every campaign uses every hop. Google Search will not let you redirect at all — see parallel tracking — so there the ad points straight at your page and the tag opens the click instead. A store campaign has no second hop, because the visitor buys on the page they landed on.

#Where things live

  • Clicks, conversions and page views are in ClickHouse. That is the history you make decisions from.
  • Campaigns, offers, landing pages, sources and domains are in Postgres. That is the configuration.
  • Caches, flood guards and the lander hop that /out/ resolves are in Redis.

You never touch any of them directly, but knowing which is which explains why some numbers update instantly and others are computed over a range.

One click arrivesClickHousewritten per click — clicks,conversions, page viewsPostgresread per click — campaigns,offers, landers, sourcesRedisread and written — caches,flood guards, the /out/ hopYou never touch any of them directly — but which is which explains what updates instantly.
One click touches all three stores. Which one answers a question is why some figures move as you watch and others are computed over a range.

If you are setting up for the first time, start with your first campaign. If you already have one and something is not working, troubleshooting is organised by symptom.

#The whole of it

Setting up — traffic sources and the macros that decide whether your sub-ids and your cost are real, affiliate networks, offers and landing pages, campaigns and flows, and your own tracking domain.

Tracking — the tag, tracking URLs, parallel tracking for the platforms that refuse a redirect, the call to action, and every token you can put in a URL.

Measuring — postbacks from a network, and goals on a page you own.

Reporting — the figures, exactly, the four screens that summarise, the logs for when a total will not say why, and how a visitor was identified.

Protecting a campaign — bot detection, and hiding a landing page from people it is not for.

Tools — smartlinks, the data corrector for backfilling what a broken postback never delivered, and integrations and geo databases.

Your account — team and settings.