What signal engineering involves: a recap of our workshop

Timo and I ran a workshop on signal engineering with Itai from Voyantis, who has spent over a decade working on signals to the ad channels, including leading app signals product strategy at TikTok. This is a recap of what we covered. What got us into the topic in the first place was a conversation between Itai and Eric Seufert on Eric’s podcast. Worth a listen if you want the full background.

Signal engineering is choosing which events you send, when, and at what value

Signal engineering is deciding which events you send back to the ad platforms, when you send them, and what value you attach to each one. The job is to tell the platform who a good user is, so it can go and find more of them.

That sounds like something we’ve always done. We’ve been sending conversion signals back since digital advertising started. What’s changed is how much the platforms now do with that signal, and how little else you control.

Automated buying means the signal is the main thing you still control

Running campaigns used to be manual. You picked the audiences, the bids, the creative, the landing pages, and you adjusted them constantly. Agencies still call it trading.

Most spend now goes through automated buying: Performance Max on Google, Advantage+ on Meta. You don’t pick the audience, the copy is generated, and the platform chooses which of your pages to send people to. It decides who sees the ad.

The one thing you still control is the signal. And the platform optimises toward whatever you send it. If you optimise for leads and treat every lead as equal, you get the cheapest leads, because that’s what you asked for. If you pass a value that says this lead is worth 150 and this one is worth 5, the platform has something better to aim at.

WYSIWYG: What you send is what you get.

That is what signal engineering does: it defines a good user, then translates that into something the platform can bid against.

It runs as a four-phase loop, not a one-off model

Signal engineering isn’t one model. It’s a loop with four phases, and most teams put nearly all their attention on the first one.

1. Predict. A model estimates the value of a user from what you know so far.

2. Translate. You adapt that prediction for each platform, because their requirements differ. Meta wants the signal fast and won’t take much history; Google gives you more time.

3. Activate. You send it back. This is more than a script running somewhere: if signal engineering matters to your spend, this becomes critical infrastructure, and you need to know quickly if it goes down or match quality drops.

4. Learn. You check what actually happened to the users behind the signals you sent, and feed that back in. This runs on its own track, alongside your attribution rather than inside it, so you need to keep a record of every signal you send.

If four teams each own one phase, it breaks

We’ve seen these four phases split across teams: data science owns predict, translate gets skipped, data engineering or marketing handles activate, and learn happens ad hoc. That’s where it breaks.

It doesn’t have to be one team doing all the depth. But one person or team has to own the whole loop, or parts get dropped. It’s continuous work, not a one-off setup, and it crosses teams that don’t usually work together closely.

Three things to be honest about before you start

• Users vary in value, and you probably already model this for retention or lifetime value. That understanding is the foundation here.

• Volume matters. These are prediction models and feedback loops. Below a certain signal volume, and a certain spend, there isn’t enough for the system to learn from. If you’re still finding product-market fit, this likely isn’t for you yet.

• You need to see value early, and how early depends on your model. A product-led SaaS can read a lot from the first 24 hours. If your real value shows up much later, you’ll need to find proxies for it. There’s no general answer, which is the point: you work it out for your business.

Timing, value, and cadence are the three decisions to make

• Timing is when you send the signal, and it’s set by the platform. Meta wants it early, ideally within the first hour and not much use after seven days. Google gives you longer, so you can wait, collect more, then decide. With long sales cycles you’re making an early bet on a proxy rather than waiting for the real outcome.

• Value is what you send. You don’t need full lifetime-value modelling to start, but you do need a reasonable view of it, and you should segment: is this the right value for users from this campaign, this platform?

• Cadence is how often you update. Google takes changes in both directions. Meta only accepts increases, so you can’t walk a value back down. What the right cadence is, you find by testing.

Monitor it, or it quietly narrows your traffic

One client optimised for people who called them, because calls closed well. The traffic shifted toward people likely to call, which worked, but it quietly missed everyone who would have booked directly without calling.

What you signal is what you get, so monitoring isn’t optional. Break the results down and check you’re not optimising yourself into one narrow group.

You’re aiming for better users, or the same users cheaper

Most teams want one of two things: better-quality users at the same spend, or the same users at lower spend. Both are testable. Run a pilot, compare against your data, and you’ll see which you got.

And keep the limits in mind. You’ll live with gaps here, often bigger ones than in attribution, because you’re acting earlier with less certainty. The aim isn’t a perfect signal. It’s a signal good enough to point the platform in the right direction, that you can keep improving.

We’ve started building the datasets and architecture for this on client projects. If you want to talk through what it would take for your own setup, book a call with us.