Ad tracking meaning
Ad tracking is not one system. It is three separate layers stacked on top of each other, and most confusion about the term comes from treating them as one thing. Knowing which layer a question is actually about is what determines whether the answer is a pixel, a device setting, or a URL parameter.
Platform-side tracking is the layer Meta, Google, and TikTok each run inside their own ecosystem, using pixels and SDKs installed on the advertiser's site or app. It belongs entirely to the ad platform. Cross-app device tracking works differently: identifiers like Apple's IDFA and Android's advertising ID let an advertiser recognize the same device across different apps, which is what makes it possible to know that someone who saw an ad in one app later converted in another. URL-based tracking is the third layer, and it does not touch a device at all. UTM parameters and click identifiers like gclid and fbclid ride inside the link itself; they only need the URL to survive the click.
Ad serving vs ad tracking
Ad serving and ad tracking happen on opposite sides of the same event, and mixing them up is the most common mistake in how people talk about this space. Ad serving is the decision layer: an ad server picks which creative to show, in which slot, to which audience, and wins or loses that placement through an auction, before the impression happens. Tracking picks up after that. It records what happened once the ad was actually shown or clicked, which is a separate job from choosing what got shown in the first place. A platform like Google Ads does both jobs inside one product. That overlap is why the two get conflated, even though they are functionally distinct steps that different parts of an ad stack are responsible for.
| Ad serving | Ad tracking | |
|---|---|---|
| Timing | Before and during the impression | During and after the impression |
| Job | Choose and deliver the creative | Record what happened |
| Typical tech | Ad server, bidding engine, targeting rules | Pixel, SDK, click ID, UTM parameter |
| Output | An impression or a served ad | Impressions, clicks, and conversions logged |
| Owned by | The ad platform | The ad platform, plus whatever the advertiser controls downstream |
Limit ad tracking on iPhone
This phrase refers to Apple's App Tracking Transparency framework, introduced in iOS 14.5 in 2021. Before that update, apps could read a device's IDFA by default and use it to track that device's activity across other apps for advertising purposes. ATT flipped the default: an app now has to show a permission prompt and get explicit consent before it can access the IDFA, and a user can also turn tracking off globally in Settings, under Privacy and Security, then Tracking, which blocks every app from asking again.
Most people who deny that prompt or switch the setting off are not blocking the ad itself. They are cutting the cross-app device identifier, the middle layer described above. The ad still gets served, the platform still counts its own impressions and clicks, and any UTM parameter or click ID attached to the URL still arrives intact when someone taps through. What disappears is the ability to stitch that person's activity together across separate apps using a shared device ID. That gap is why advertisers leaned harder on aggregated measurement like SKAdNetwork, and on URL-based tracking, after 2021. The layer Apple restricted is real and it mattered, but it is one of three, not the whole system.
Why URL-based tracking mattered more after 2021
When ATT cut off easy cross-app device matching, the layer that never depended on a device identifier in the first place became the one advertisers could still rely on without asking Apple's permission. A link carrying UTM parameters or a platform click ID like gclid or fbclid does not need to identify a device across apps. It only needs to survive from the ad to the landing page in one continuous click. That is a much lower bar than cross-app matching. URL-level tracking, decoding what a click actually carries and logging it against a specific link, looks like the least technical layer of the three, and it is the one that got more useful after 2021, not less.
What Raydar actually tracks, and what it does not
Raydar sits at the URL-based layer. Every click on a Raydar bio link, the kind of setup covered in link-in-bio analytics, or a tracked link is logged with its UTM values, referrer, and first-touch and last-touch cookies, which answers a specific and useful question: which post, platform, or campaign produced this click, down to country and city level geo on the click itself. That is genuinely link-level ad tracking, and it works regardless of a phone's tracking permission setting, because it never depended on a device identifier in the first place.
It is not full ad tracking in the platform sense, and being honest about that boundary matters more than the feature list. Raydar can only see activity on the pages and links it actually serves. Once someone leaves that page and lands on a separate website, whatever they do there, browsing, adding to cart, buying, is invisible to Raydar unless that destination site reports back through its own UTM-aware analytics or a shared campaign tag. A tracking pixel embedded on someone else's checkout page is a different category of tool from a tracked bio link, and no bio link platform, Raydar included, replaces that. What a tracked link answers well is the click; what happens after the click leaves Raydar's view is the destination site's job to report.