Opensend
A commerce identity and activation platform I helped build from the storefront signal to the merchant's next action.
What it had to do
A useful identity platform has to connect two worlds that disagree about almost everything. The storefront sees anonymous visits, page context, carts, and sessions; the merchant needs people, audiences, destinations, consent, and a way to understand whether any of it worked.
The job was not just to resolve an identifier. It was to build the acquisition surfaces that collect trustworthy signals, the control plane merchants use to configure the system, and the activation loop that turns resolved identity into selective, measurable action.
- site visits processed in a month
- 175M
- shopper identities resolved in a month
- 35M
- new-to-client identities delivered
- 6M
Explore the system
Step through the three curated paths without changing the diagram.
The acquisition and control-plane surfaces were built as first-class products, not integration glue. Identity, consent, audience configuration, delivery state, and performance then meet at explicit boundaries rather than leaking into one another.
How it moves
- 01
Capture
The browser SDK and commerce integrations collect behavioral and transactional signals while preserving the context needed to understand them later.
- 02
Normalise
Platform-specific payloads are validated, deduplicated, enriched with storefront context, and translated into a stable internal event shape.
- 03
Resolve
Anonymous activity and known customer signals meet in the identity layer, which returns the best available profile without blocking collection.
- 04
Govern
Enrichment and suppression rules determine what may be used, what must be withheld, and which merchant configuration applies.
- 05
Activate
Audience membership and destination connections turn the resolved profile into work for the channels a merchant has deliberately enabled.
- 06
Learn & recover
Delivery state and performance reporting close the loop, while re-engagement workflows provide a controlled path for signals that need another chance.
Identity is a process, not a lookup
Capture once. Resolve carefully. Activate selectively. Measure the result.
Anonymous becomes known
The journey can begin without an identity. State is preserved so a later customer signal can connect useful context without holding up the storefront.
A destination slows down
Delivery work remains separate from collection and resolution, so a provider problem does not make the merchant lose the original signal.
Permission changes
Suppression is treated as part of activation, not a cleanup job. A profile can be withheld even when it is technically resolvable and deliverable.
What I actually did
Built the storefront acquisition layer
I built the browser SDK and commerce-platform surfaces from the beginning: event collection, client state, session context, platform adapters, and the path that turns raw storefront behavior into dependable input for identity resolution.
Built the merchant control plane
I built the merchant-facing application and its backend foundation from the beginning — onboarding, tenant-aware configuration, integration setup, billing lifecycle, account management, and the operational screens that make the platform usable without an engineer in the room.
Worked the identity layer after resolution
My work in the identity platform focused on enrichment, suppression, event delivery, and reporting: the parts that decide whether a resolved profile is useful, permissible, observable, and ready to leave the system.
Turned identity into activation
I built audience and segment management, destination connections, and the configuration paths that let merchants decide which people should go where — without coupling the storefront to any particular downstream provider.
Closed the loop
Performance reporting made delivery visible, while re-engagement and recovery workflows gave incomplete or missed opportunities a deliberate second path instead of hiding them as silent loss.
What changed because I was there
Product names, provider details, and internal boundaries are intentionally generalised. The ownership, product areas, and scale are representative of my work.
- 01
One acquisition surface across storefronts
Created a consistent collection model across the browser SDK, embedded commerce surfaces, and server-side events while keeping platform-specific behavior at the edge.
- 02
A control plane merchants could operate
Established the application architecture and backend domains that let merchants onboard, configure integrations, manage access and billing, and inspect the state of their account.
- 03
Audiences as a product boundary
Built audience and segment workflows as reusable merchant concepts rather than burying selection logic inside individual destination integrations.
- 04
Destinations that stayed replaceable
Kept connection setup and delivery configuration behind common product flows so channels could evolve without rewriting the acquisition experience.
- 05
Performance joined configuration
Connected reporting back to the merchant surfaces, making activation something a user could configure, observe, and evaluate in the same product.
- 06
Recovery became an explicit workflow
Built re-engagement paths for valuable signals that were not ready on the first pass, with visible state and a controlled route back into activation.