Siren's Tracking System is Bananas

One of the hurdles I’ve had to overcome when building Siren was how do I handle the tracking cookie? It’s a necessary piece in any affiliate program, since you never really know up-front whether a visitor can be identified by something more reliable, like a user ID. Older systems call these “visits” or “visit IDs”, and they treat the click that produced the visit as the only thing worth tracking. Siren uses a more generic term, opportunities, because the click is only one of many things an affiliate program might want to count.

A visit can only be one thing, a person who showed up on your site, app, or whatever. An opportunity can be anything. That difference is the reason everything else in Siren works the way it does, and it’s the reason the design is aging well as AI agents start to complete purchases on behalf of the people who used to do the clicking.

Old Affiliate Plugins See Clicks, Siren Sees Opportunities

The nerdy definition I came up with for an opportunity is:

A single instance of something from which rewards can be issued. Generally created from, and tracked using, cookies. Usually represents a site visitor, but could be other things.

Someone visits your site? Opportunity. A salesperson adds a record to a CRM? Opportunity. A new bug gets filed on your bug bounty program? Opportunity. A pitched blog topic gets added to your content board? Also an opportunity.

This means the input for a program doesn’t have to start with a site visit, or even a person at all. It doesn’t have to start with a click, either, which is the part that’s quietly become important. The people who choose Siren can build programs that look nothing like an affiliate program if they want to, and they can also build programs that look exactly like an affiliate program but fire on something other than a click.

A visitor-triggered affiliate program. A pay-per-lead program where opportunities are created when someone fills out a contact form. A support performance incentive program where opportunities are created when someone opens a ticket. A blog content program where a pitched post is marked as an opportunity for writers to claim. A GitHub issue flagged as a bug bounty item that becomes an opportunity for a programmer to fix. An AI agent routing a purchase through Google’s Universal Commerce Protocol or Shopify Agentic, where the “click” never really happened but a content partner still influenced the decision. All of these are the same shape to Siren. The attribution logic downstream doesn’t care what fired the event.

By controlling the input for an opportunity, you can create the basis that the rest of any performance-driven program can run on. This opens up a way to build business systems that are gig-based and, prior to Siren, were genuinely not easy to set up. It also opens up something I didn’t fully appreciate when I first sketched this out, which is that the trigger for an opportunity doesn’t have to be a human action at all. It can be an event, and events are exactly what the new wave of agentic-commerce patterns (ChatGPT’s in-chat checkout, Google’s UCP, Shopify Agentic) are producing in the places the click used to live.

Imagine empowering contractors to pick up small, measurable tasks in your business automatically. Imagine a content partner who gets credit for a sale that never touched their link because their post is bound to the product the reader bought, and the reader bought it by asking an AI assistant. How would that change how you run your business now?

Why Hardcoding “The Click” Ages Badly

When I wrote the first version of this post in 2024, I argued that hardcoding a click as the only trigger forecloses too many other program shapes. That was the motivation I led with. Two years in, there’s a second reason that matters at least as much, and it’s the reason I went back and reworked this piece.

Click-only attribution is weakening in the channels most exposed to AI. Organic discovery especially. When a reader asks ChatGPT “what’s the best WooCommerce affiliate plugin”, the assistant can cite a content partner’s post, form an opinion, and route the reader straight to checkout without any click fingerprint ever reaching your server. Owned and direct channels (paid ads, branded email) still have intact click signals, so this isn’t a full collapse of click attribution. It’s a slow drift in the organic and AI-mediated slice, and operators who only track clicks are watching their attributed numbers soften even when their content partners’ work hasn’t changed.

An Opportunity in Siren can be triggered by any attributable event. A click, sure, but also a coupon, a product-ownership mapping, a bound post visit, a form submission, or an order-created event on a partner-specific product. The attribution logic downstream is identical regardless of what fired the event. That’s the design choice that matters right now. The same system that tracked a visit in 2024 can bind attribution to a content partner’s post in 2026, and the conversion fires correctly whether the reader clicked through, bought directly, or routed the purchase through an AI assistant. I walked through the full landscape in the pillar on affiliate attribution in the age of AI agents, and the technical how-to for WooCommerce operators specifically lives in building a WooCommerce affiliate program that survives agentic commerce.

That does not mean every unattributed order is AI-driven. It means you have a better place to attach attribution when the click trail stops being useful.

Launch Day Capabilities

At launch, Siren supports the basic visitor flow, where an opportunity is created when someone visits your site. That opportunity is tracked with a cookie, the same way older programs do it. The difference is that the cookie is one of many ways to create an opportunity, not the only way, which is why newer attribution signals (order-bound products, coupon-bound partners, AI-routed purchases that never produced a click) can plug into the same machinery without me having to re-architect anything.

I plan on using Siren in my own business a ton, so I’ll be building integrations that automate opportunity creation in different ways as they come up. I’ve already announced work on integrations with other plugins like WooCommerce and LifterLMS, and there will be many more nifty ways to handle this. The WooCommerce one is where the agentic-commerce wiring is going to matter first, because WooCommerce is where most of our earliest operators run their checkouts.

Something I’ve spent a fair bit of effort thinking about is tracking data. I strongly believe in user privacy, and I think GDPR is, on balance, a good thing. Which, on the surface, might make the idea of building affiliate tracking software feel awkward.

But I think it’s actually a good opportunity to build software that respects a user’s privacy and also tracks what’s needed for a performance system to work. When you design for GDPR from day one, it’s possible to build something that’s easy to manage. It also turns out that designing for privacy and designing for agentic commerce pull in the same direction, because both of them require you to stop leaning on a brittle client-side click trail and start leaning on server-side attribution signals you already own.

This is a small taste of what makes Siren different from what you’ve seen before. The platform was built from the ground up as a departure from what you know about affiliate programs, and the 2024 decision to track opportunities instead of visits is the reason it can absorb the shift to AI-mediated checkout without me having to rewrite its core. I honestly believe entire businesses can be run using a series of well-built incentive programs, and I hope Siren helps operators connect their goals to the contractors, partners, and content creators who work with them. We have a lot more to talk about.

Swim fast, dream big!