01Insights · The Mechanism
How In-Session Decisioning Works
Most marketing acts hours later. We act in milliseconds. Below is the five-stage loop that turns an anonymous click into a personalized action before the visitor bounces.
- Anonymous bounce window
- 8–30s
- Average decisioning window in legacy stacks
- hours – days
- Convertive decisioning window
- < 100ms
The loop
Five stages, under 100 milliseconds
Each stage runs in parallel where possible. Total budget from event to rendered action is below the threshold a human eye registers as latency. That is the only window that matters — the bounce window is shorter than most dashboards refresh.
0 / 100 ms
Latency budget per stage, slowed down about 60× so you can watch it.
01Event ingest
Every click, scroll, hover, add-to-cart, and source signal streams off the page into a low-latency event bus the moment it happens. No batch jobs. No nightly ETL.
Latency budget
< 10ms
02Live profile
Events update an in-memory profile keyed to a cookie or device ID. If identity arrives mid-session — email, login, phone — the anonymous trail is stitched to the known profile in real time. The profile is enriched, never re-built.
Latency budget
< 20ms
03Intent inference
Browsing sequence, dwell time, price-point pattern, and source context feed predictive scores: propensity to convert, bounce risk, price sensitivity, category affinity. The system infers what the visitor wants before they tell you.
Latency budget
< 30ms
04Next-best-action ranking
Multiple eligible actions — discount popup, product rec carousel, free-shipping banner, identity capture, cart save, do nothing — are scored against the live profile. The single highest-expected-lift action wins. Conflicts and message fatigue avoided.
Latency budget
< 30ms
05Render + log + learn
Selected action injected via the on-site SDK. Outcome logged: clicked, ignored, converted, bounced. The learning loop updates the policy so the next session benefits from this one.
Latency budget
< 10ms
Stage 01: Event ingest, < 10ms.
Architecture
What sits underneath
- Streaming pipelineShopify app + JS SDK push clickstream events into a real-time bus. Modern stream processing fans events out to the profile store, decision engine, and analytics in parallel.
- In-memory live profilePer-visitor profile kept hot for the active session. Avoids cold reads against a warehouse during the decision window. Identity stitched on-the-fly when email or login arrives.
- Decision engineContextual bandit / ranker scores eligible actions per profile. Rule fallbacks when confidence is low. Holdouts preserved for measurement.
- Outcome + learning loopEvery impression and outcome feeds back. Policy updates without manual A/B test cycles. The system gets sharper as more sessions flow through.
Seven capabilities
What in-session decisioning must do
A platform either delivers all seven or it is not in-session decisioning. Triggers and rules cover one or two. CDPs cover identity but not action. Popups cover action but not intent. The full loop is the bar.
Your stack today
0 / 7
Tick what your current stack does. Anything short of all seven is a slice, not the loop.
Questions
Asked often.
What does "in-session" actually mean in technical terms?
A decision computed and rendered before the user navigates away from the current page or browser tab. End-to-end latency under 100ms — event ingest, profile update, scoring, action selection, and DOM render — measured against the user's active session, not against a backend schedule.
How is this different from a marketing automation platform with real-time triggers?
Marketing automation triggers fire on rules ("cart abandoned for 30 minutes → email"). In-session decisioning ranks every eligible action by predicted lift for the live profile, picks one, and renders it before the visitor bounces. Triggers react to time. Decisioning reacts to intent.
Does the mechanism require ripping out our existing stack?
No. Convertive layers on top of Shopify, your ESP (Klaviyo, Braze), your CDP, and your ad platforms. The mechanism consumes events from those systems and emits decisions back to them — popups on-site, suppression signals to ESP, audience syncs to ad platforms.
How does the system avoid showing conflicting offers?
The next-best-action ranker is a global selector. When multiple campaigns are eligible — say a discount popup, a product rec, and an email capture — the ranker picks one based on expected conversion lift for that profile. Frequency caps and mutual exclusivity rules enforce one-action-per-session-stage discipline.
What happens if the AI service is slow or unavailable?
Fallback to a cached rule-based decision so the user still sees an action. The system is built to fail gracefully — a slower, simpler decision is better than no decision before the bounce.
See the loop run on your store.
Free 12-hr ROI audit modeled on your traffic. No card. No commitment.