Why I built Datafly Signal

I’ve spent the decade before Datafly building first-party data infrastructure for enterprise. Thousands of conversations with marketing data teams, and one recurring pattern: the people responsible for marketing data are flying blind, and the tools available to them were designed for a world that no longer exists.

The world we built these tools for

2014 vintage: cookies last 2 years, cross-site tracking is normal, a vendor pixel on your page more-or-less works, iOS ATT is six years away, GDPR is four, ad blocker penetration in the enterprise segments is below 10%. The natural architecture is obvious: put the vendor’s JavaScript on your page, let them do the tracking, receive the reports. The big tag managers and CDPs are all fundamentally this pattern, with different pricing models and different amounts of data-layer plumbing.

The world we have now

2026: Safari caps client-set cookies at 7 days, Firefox blocks cross-site cookies outright, iOS App Tracking Transparency has decimated mobile attribution, ad blocker penetration on desktop in affluent markets is between 25 and 40 percent. Regulatory scope has expanded from GDPR into DMA, DPDP, DORA, the PCI DSS 4.0 cookie requirements, and dozens of sector-specific regimes. The natural architecture is the opposite of 2014: the vendor’s JavaScript must not be on your page, because the browser will either block it or neuter it.

What every company needs is a way to do the same tracking, but inverted: collect on the server, not in the browser. Most of the existing category knew this. Most of them added a "server-side" product line to their existing client-side platform. None of them solved the core problem, because none of them replaced the vendor scripts on the page. They just added a second layer on top.

What I wanted to build

One product. Customer-hosted. Server-side. Replaces every vendor pixel with a single first-party collector. Runs entirely inside the customer’s cloud account. Zero access from the vendor to the customer’s data plane. Ships with pre-built blueprints for every vendor API most customers care about, included in the base price, not metered per-connector.

Every one of those decisions is the opposite of how the existing category sells. Per-connector pricing is profitable; included-by-default is not. Shared-tenancy is cheap to operate; single-tenant customer-hosted is expensive. A control plane in the vendor’s cloud is easy; a control plane that runs in the customer’s VPC with the vendor having no access is hard.

Why nobody else built it

Because the incentive structure of the category is aligned against it. The biggest server-side and CDP players have built their businesses on per-MTU pricing, per-destination adapters, and product portfolios that depend on access to customer data. The existing category leaders would have to accept a structurally lower gross margin to build what I wanted, and none of them will.

So I built it. The architecture is stable, the blueprint catalogue is 130+ integrations deep, and we're now opening to founding customers — the regulated enterprises where the customer-hosted story is the one that actually clears procurement.

What comes next

There is an enormous amount of technical work ahead — deepening the blueprint library, certifying against more compliance regimes, expanding the identity and attribution engines, and polishing the operator experience for teams that want to run Signal themselves rather than as a managed service. But the core architectural bet is made: customer-hosted, server-side, first-party, included-everything. Everything we ship from here refines that shape rather than revisits it.

If you are responsible for marketing data infrastructure in 2026 and you’ve been quietly aware that the stack you inherited is from a different era, come talk to us. We’ll run a Live Tag Scan on your site in 20 minutes and show you what the alternative looks like.