A client wanted to focus their ad campaigns more on website visitors and work with lookalike audiences. Before we talked about audiences, we checked whether the necessary signals were even arriving cleanly. Our proposal was a package in this order: set up tracking, run a small test campaign, and only then audiences and the main budget. Along the way, we made clear which earlier campaign wasn't ours. That's part of clean work, too.
The case
Ad platforms optimize for what gets reported to them. If the store doesn't reliably report purchases, carts and page views, the platform optimizes on incomplete data. Audiences built from website visitors stay small, lookalike audiences get fuzzy, and the budget flows in the wrong direction.
Pixel and server-side API, simply explained
| Pixel in the browser | Server-side transmission | |
|---|---|---|
| How | Code in the browser reports events | The store reports events directly to the platform |
| Strength | Quick to set up | Less vulnerable to blockers and browser restrictions |
| Weakness | Often blocked or incomplete | Needs a clean setup |
| Together | Complement each other when duplicate events are deduplicated properly |
The order we recommend
- Set up and check tracking. Are page views, carts and purchases all coming through?
- Run a small test campaign. It reveals technical errors before the big budget goes live.
- Build audiences. From visitors, buyers and prospects, once the data is right.
- Only then scale. With lookalike audiences and the main budget.
Your takeaways
- Optimization is only as good as the signals. Check your tracking before you fine-tune audiences.
- Use pixel and server-side transmission together. That way, more events arrive reliably.
- Test small before you spend big. A test campaign is cheaper than a month of bad data.
- Be clear about responsibility, too. An agency should only answer for what it built itself.
Are your campaigns running, but the results are hard to read? We first check whether the right signals are coming through.