---
title: "What is a conversion pixel? | daily.dev Ads glossary"
url: https://business.daily.dev/glossary/conversion-pixel/
description: "A conversion pixel is a script on your site that tells an ad platform when a visitor it sent does something: signs up, starts a trial, activates. It connects the ad to the result, days later or without a click."
lastUpdated: "2026-10-20"
llmsTxt: https://business.daily.dev/llms.txt
---

## What is a conversion pixel?

A conversion pixel is a script on your site that tells an ad platform when a visitor it sent does something: signs up, starts a trial, activates. It connects the ad to the result, days later or without a click.

Also called: Tracking pixel, Conversion tracking.

Without a pixel, an ad platform can report impressions and clicks and nothing after. With one, your site fires an event at each step you care about, and the platform matches it to the person it reached. The match uses a cookie, or better, a first-party identifier you pass (a hashed email or your own user ID), so a sign-up on another device still connects to the ad.

The events to track follow the developer funnel: sign-up, first successful use, team invite, upgrade. Tracking only the sign-up rewards campaigns that bring curious visitors; tracking activation rewards the ones that bring developers who stay.

A pixel is a privacy decision as well as a measurement one. Load it with consent where the law requires it, pass hashed identifiers rather than raw ones, and say in your privacy policy what it does. Developers read privacy policies.

## How does a conversion pixel work?

A small script on your site loads with the page. When a visitor does something you care about, your site calls it with an event name (sign_up, activated, upgraded) and, ideally, a hashed first-party identifier. The script sends the event to the ad platform, which matches it to a person it reached: by a cookie set when they clicked, or by the identifier if they saw the ad on another device. The platform then reports the conversion against the campaign, the creative and the placement.

Server-side versions send the same events from your backend rather than the browser, which survives ad blockers and strict browsers and is the direction most platforms are moving.

## Which events should a developer product track?

- **sign_up:** the account exists.

- **activated:** the first successful use: an API call, a deploy, a build.

- **team_invite:** a second person from the domain.

- **upgraded:** a paid plan or a contract.

Tracking only sign-ups rewards campaigns that bring curious visitors. Tracking activation rewards the ones that bring developers who stay, and it is the event that predicts revenue. Pass the same identifier with every event so the platform can follow one developer through the funnel.

## How do you set a pixel up without breaking trust?

Load it after consent where the law requires consent. Pass identifiers hashed, never raw. Describe it in the privacy policy in plain words: which platforms, which events, what for. Prefer server-side events so no third-party script runs in the developer's browser. Developers read privacy policies and inspect network requests; a pixel that is disclosed and minimal is the ordinary way campaigns are measured, and a hidden tracker is the reason they run ad blockers.

## How does the daily.dev pixel report?

Click-through conversions, for developers who clicked a card and later fired an event. View-through conversions, for developers who saw the card and converted without clicking, reported separately. Matching by your hashed email or user ID, so a sign-up days later on a laptop connects to a card seen on a phone. All of it by campaign and creative in the weekly report, beside reads and follows, so the campaign manager can move budget to the placement that produced activations rather than the one that produced clicks.

**Common mistakes**

- Tracking sign-ups only, and scaling the campaign that brought the most curious visitors.
- Raw email addresses in the event payload.
- A client-side pixel blocked by the audience's ad blockers, with no server-side fallback.
- A pixel nobody mentioned in the privacy policy.

**How developers experience it**

- They open the network tab and see what you send; make it defensible.
- A disclosed, hashed, consented pixel is unremarkable to them.
- A third-party tracker loading before consent is a reason to leave.

## On daily.dev

The daily.dev [conversion pixel](https://business.daily.dev/pixel.md) reports sign-ups, trials and activations from your campaign, credits view-through conversions when a developer saw the ad and converted later, and matches conversions with your own hashed email or user ID across devices.

## Client-side pixel vs server-side events

| | Client-side pixel | Server-side events |
| --- | --- | --- |
| **Runs** | In the visitor's browser | On your backend |
| **Blocked by ad blockers?** | Often, on a developer audience | No |
| **Setup** | A script tag and event calls | An API call from your app |
| **Cross-device matching** | Cookie, plus a hashed identifier if passed | Hashed identifier |
| **Trust** | A third-party script on your page | Nothing loads in the browser |

## Go deeper

- [The conversion pixel on daily.dev](https://business.daily.dev/pixel.md)
- [Retargeting developers, privacy first](https://business.daily.dev/resources/retargeting-developers-privacy-first-guide.md)
- [Marketing attribution for developer products](https://business.daily.dev/resources/marketing-attribution-for-developer-products-what-works.md)

Related terms: [Marketing attribution](https://business.daily.dev/glossary/marketing-attribution.md) | [UTM parameters](https://business.daily.dev/glossary/utm-parameters.md) | [Developer acquisition](https://business.daily.dev/glossary/developer-acquisition.md)


### Frequently asked questions

**What events should a developer product send to a conversion pixel?**

More than the sign-up: first successful use, team invites and upgrades. Campaigns that bring developers who activate are the ones worth scaling, and only the later events show that.

**How does a pixel credit a sign-up on another device?**

By matching a first-party identifier such as a hashed email or your user ID, passed with the event, to the person the ad reached. That matches a sign-up days later on a laptop to a card seen on a phone.

**Do developers object to conversion pixels?**

They object to opaque tracking. A pixel loaded with consent, passing hashed identifiers, described plainly in the privacy policy, is the ordinary way campaigns are measured. Hidden third-party trackers are what ad blockers exist for.

**Should the pixel be client-side or server-side?**

Server-side where you can. It survives ad blockers and strict browsers, keeps third-party scripts out of the developer's page, and sends the same events from your backend.

**What is a view-through conversion in pixel reporting?**

A conversion by a developer who saw the ad and later fired an event without having clicked. It is reported separately from click-through conversions so you can see the campaign's effect beyond the click.

[All terms](https://business.daily.dev/glossary.md) | [Explore your options](https://business.daily.dev/schedule/?ref=glossary-conversion-pixel) | [How pricing works](https://business.daily.dev/pricing.md)