Sending warehouse data back out to the ad platforms.

Reporting reads the warehouse so a person can look at it. Activation reads the warehouse and writes to a platform: an audience to target, a conversion the platform never saw, a customer status the CRM ought to know about.

Same tables, opposite direction. The pattern has a name, reverse ETL, which describes the plumbing rather than the point. The point is that decisions get made by systems as well as by people, and the systems are currently deciding on less than you know.

The definitions are already there. What a valuable customer is, what lapsed means, which sale counted, all of it written in SQL beside the metric definitions the reports use.

Build the same segment separately inside each platform and you now maintain it in each, and they drift, quietly, in the direction of whoever edited one last. One definition pushed to several destinations is the same argument as one metric name read by several reports, applied to the half of a client's business that spends money rather than the half that reports on it.

Almost all of it is one of these.

• Audiences

  Customers matching a condition you can express in SQL: bought more than once, lapsed, high value, signed up and never activated. The warehouse is often the only place that knows two of those at the same time, because each platform knows its own slice.

• Outcomes the platform never saw

  A sale closed by a person, a subscription that survived its refund window, an order cancelled a week later. Platforms optimise against what they are told, so a platform told only about the first event optimises for the first event, which is rarely the one the client is paid for.

Four things, and none of them is the initial setup, which is the part that gets estimated.

Identity, because you need something to match on and how well the matching works decides whether any of this was worth doing. Consent, because what you are permitted to send is not the same set as what you hold. Frequency, because how often you push is a decision about how stale an audience may be, and more often costs more on both sides.

And failure handling, which is the one that bites. A push that fails quietly leaves a platform optimising against a list that has stopped being updated, which is worse than never having sent it, because now there is confidence behind it.

Sending an outcome back without checking that it means the same thing on both sides. If the platform counts a conversion at one moment and you count it at another, feeding yours in does not correct the platform. It trains it against a target you have not looked at carefully.

Definitions matter more here than they do in reporting, and it is worth being explicit about why. A wrong definition in a report misleads a person, who can ask a question. A wrong definition in activation changes where a client's budget goes, continuously, and nothing asks anything.

It does not do this part. SightShark ingests from each client's sources, lands the data in a warehouse you own, models it and reports on it. Pushing data back out to platforms is a separate tool or a separate piece of work, and there is no version of this page where that stops being true.

What it does supply is the half that decides whether activation works at all. One name per metric, one type, one grain and one currency, in tables inside your own cloud, which is where an audience definition and an outcome definition can live once and be read by anything. Add an activation tool later and it reads those tables, which is a considerably better starting position than defining the same audience separately in four platforms.