Proof of concept for turning real-time website behaviour into campaign-ready customer signals.
Software Engineer · Contract · Dec 2025 – Feb 2026
This repository documents the system and engineering work I contributed to at a stealth startup. Source code is not public.
Most analytics tools tell you what happened after the fact.
This project explored a different question:
Could a client understand what a visitor seemed interested in while they were still browsing?
The proof of concept focused on capturing high-signal website behaviour, turning those events into persistent behavioural profiles, and using that context to inform campaign recommendations.
- Captures first-party website activity through an embedded browser SDK
- Tracks page views, clicks, searches, form engagement, product views, and content interest
- Preserves session flow and referrer context
- Uses permitted identifiers to connect anonymous activity to durable profiles when available
- Normalizes raw events into structured behavioural signals
- Groups repeated activity into profile-level interests and traits
- Uses those profiles as context for campaign recommendations
Visitor browses website
↓
Browser SDK captures activity
↓
Events stream into backend
↓
Pipeline normalizes behaviour
↓
Sessions are stitched
↓
Behavioural profile updates
↓
Inference layer
↓
Campaign recommendations
- Worked on a browser SDK embedded directly into client websites
- Captured high-signal interactions without requiring clients to rebuild their product
- Built around first-party behavioural data rather than only aggregate analytics
- Helped shape the event pipeline from raw browser activity to structured profile signals
- Grouped repeated actions into longer-lived interests and behavioural traits
- Used permitted identity signals to connect sessions when available
- Explored an inference layer for turning behavioural context into campaign suggestions
- Kept explainability and source context in mind when working with inferred traits
Browser SDK · Event Ingestion · Behavioural Analytics · Session Stitching · Profile Building · Inference
The SDK focused on interactions that could help explain user intent.
visits
page views
referrers
session flow
These provided context around how someone arrived and how they moved through the site.
clicks
searches
form engagement
product views
content views
repeated category interest
The goal was not to collect more counters.
It was to identify actions that could become useful context for a marketing decision.
When permitted, an email or other known identifier could be used to connect otherwise anonymous activity to a durable profile.
That made it possible for behaviour across sessions to contribute to the same customer context.
Client website
↓
Browser SDK
↓
Event ingestion
↓
Normalization
↓
Session stitching
↓
Profile construction
↓
Inference
↓
Campaign recommendations
The interesting part of the system was the middle.
Raw browser events are noisy on their own.
The product needed a way to move from:
"viewed product"
"clicked category"
"searched keyword"
"returned to page"
to something more useful:
repeated product interest
category affinity
emerging intent
campaign context
The system therefore treated event capture, profile construction, and inference as separate stages.
The profile layer grouped repeated actions into longer-lived context.
raw event
↓
normalized behaviour
↓
session context
↓
repeated pattern
↓
profile trait / interest
That made the profile more useful than a simple list of recent events.
The challenge was deciding:
- which signals were meaningful
- how long they should matter
- when repeated activity should become a trait
- how confident the system should be in that inference
- how the recommendation could be explained later
I worked on this as a contract Software Engineer at a stealth startup.
The product was exploring a marketing intelligence system that could react to customer behaviour while it was happening rather than relying only on retrospective analytics.
My work touched:
- the browser SDK
- event ingestion
- profile construction
- behavioural signal processing
- the inference layer
Because the company was stealth, the implementation itself is not public.
This repository exists to document the architecture, product thinking, and engineering problems I worked on without exposing proprietary code.
Signal pipeline
A simplified version of the flow:
SDK captures activity
↓
Events stream in
↓
Pipeline normalizes behaviour
↓
Sessions are connected
↓
Profiles update
↓
Campaign context is generated
The backend had to turn individual actions into something that could be reasoned about at the profile level.
For example:
product page view
+
repeat visit
+
related search
+
category click
↓
stronger product / category interest
The goal was to create cleaner context for downstream marketing decisions.
Product considerations
The technical problem went beyond event collection.
A useful behavioural system also has to answer questions like:
- Which interactions are worth collecting?
- How long should a signal remain relevant?
- When should an inferred trait decay?
- How should anonymous and identified sessions connect?
- How should confidence be represented?
- Can a human understand why a recommendation was made?
A behavioural profile is not the same thing as ground truth.
Inferred traits should remain distinguishable from known facts.
Privacy and explainability
More personalization is not automatically better.
The system had to balance useful targeting with:
- consent
- permitted identity use
- source context
- explainability
- uncertainty around inferred traits
One of the main lessons from the project was that a good data product needs a clear signal chain.
source event
↓
derived signal
↓
profile trait
↓
recommendation
If that chain cannot be inspected, it becomes much harder to trust the output.