Everything you need to map your activation funnel, configure churn scoring, and launch your first behavioral nudge.
Install the SDK and get your first event flowing in under 30 minutes. Covers both JS SDK and Segment destination setup.
ReadHow to track user events, define custom properties, and structure your event schema for activation modeling.
ReadMap your events to activation steps. Define what "activated" means for your product and create custom funnels.
ReadHow the behavioral scoring model works, what signals it watches, and how to interpret churn risk scores.
ReadBuild checklists, tooltips, and banners. Set trigger rules by event, delay, or churn risk score. No code required.
ReadFull REST API documentation. Custom event ingestion, user scoring endpoints, webhook configuration, and rate limits.
ReadThere are two ways to get data into Onboardvue: the JavaScript SDK (a small script tag you drop into your app) or the Segment destination (if you already use Segment, this takes about 5 minutes). Both paths land events in the same pipeline.
Add the loader snippet to the <head> of every page. Replace YOUR_WRITE_KEY with the key found under Settings > Sources in your workspace.
/* 1. Load the SDK */ <script> (function(w,d,k){ w._ovq = w._ovq || []; var s = d.createElement('script'); s.async = true; s.src = 'https://cdn.onboardvue.com/v1/ovue.min.js'; d.head.appendChild(s); w._ovq.push(['init', k]); })(window, document, 'YOUR_WRITE_KEY'); </script>
Call identify() as soon as a user signs in. Pass a stable user ID and any traits you want available for milestone conditions and churn scoring.
_ovq.push(['identify', { userId: 'usr_8a4f2c', email: '[email protected]', plan: 'growth', createdAt: '2026-04-11' }]);
Track meaningful user actions with track(). The event name becomes the building block for activation milestones. Keep names in past tense and use snake_case or Title Case consistently across your schema.
_ovq.push(['track', 'Dashboard Viewed', { dashboard_id: 'db_main', view_source: 'onboarding_checklist' }]);
Open the Live stream view in Onboardvue (Workspace > Live stream). Trigger the action in your app. You should see the event appear within 2-3 seconds. If it does not appear after 30 seconds, check the browser console for a network error on the /v1/events endpoint and confirm your write key is correct.
In Segment, go to Connections > Destinations > Add destination, search for Onboardvue, and paste your Destination API key (found under Settings > Sources > Segment in your Onboardvue workspace). All identify and track calls from your existing Segment setup will forward automatically. No SDK install needed.
Activation scoring is only as good as the events feeding it. An event schema that was designed for analytics dashboards often needs a small amount of restructuring before it works well as behavioral signal input. Here is what to think about before you start tracking.
Use identify() for user attributes that describe who someone is: their email, plan tier, company name, signup date, and any dimensions you want to filter activation cohorts by. Use track() for things a user does. The distinction matters because Onboardvue joins identify traits to every subsequent track event for that user ID, so anything you put in identify() becomes an available filter everywhere in the product.
Onboardvue is not opinionated about naming style, but you should pick one convention and stick with it. We recommend object-action format in Title Case ("Report Created", "Integration Connected", "Dashboard Viewed") because it reads clearly in the milestone builder and makes alphabetical lists scannable. Avoid generic names like "Button Clicked" or "Page View" as standalone milestone signals. They carry no semantic weight and will produce noisy scoring.
Not all event properties are equal. Properties that make events useful for activation modeling tend to be:
Avoid tracking sensitive fields (PII beyond email, payment details) as event properties. If you need to tie activation signals to billing status, pass the plan or subscription tier in identify() instead.
_ovq.push(['track', 'Report Created', { report_type: 'funnel', data_source_count: 3, created_from: 'template', // organic vs guided collaborators: 2 }]);
You do not need to track every interaction. High-frequency UI events (mouseovers, every keystroke, scroll depth in isolation) add noise without improving activation signal quality. Focus on actions that represent intent: creating things, connecting integrations, inviting teammates, completing a workflow. If you are unsure whether to track something, ask whether it would indicate a user "got value" from your product. If yes, track it. If it is purely navigational, skip it or track it only on your analytics layer without forwarding to Onboardvue.
Milestones are the named steps on your activation funnel. Each milestone maps to one or more events (with optional property filters) that confirm a user completed that step. The milestone builder sits in the Activation section of your workspace.
Click "New milestone" and give it a descriptive label that matches how your team talks about activation (for example: "Connected first data source", "Invited a teammate", "Created first report"). Then add one or more trigger conditions:
data_source_count >= 2The activation gate is the subset of milestones that, when all completed, mark a user as "activated." You choose which milestones are required. A common pattern for B2B SaaS is a 3-step gate: connected a data source, created a meaningful object (report, dashboard, workflow), and invited at least one teammate. Users who hit all three within the first 14 days show materially higher retention in most PLG products, though the exact combination depends on your product's aha moment.
We are not saying every user must follow the same path. Milestones track completion regardless of order. The activation gate just checks whether all required steps happened within the window you configure.
Set the activation window under Funnel settings. The window defines how many days after signup the gate must be completed. Onboardvue will show users who completed the gate within the window vs. those who did not, broken down by cohort. This is the primary input to churn risk scoring.
The Activation funnel view shows, for each milestone in order, what percentage of a signup cohort completed it. Drop-off points are where to focus onboarding nudges. If 70% of users complete milestone 1 but only 30% reach milestone 2, that gap is your highest-leverage intervention point. Use the Nudge editor (see below) to trigger in-app prompts at that specific drop-off.
Onboardvue computes a churn risk score (0-100) per user based on their behavioral signals over a rolling window. A score of 0 means very low observed risk; 100 means the behavioral pattern matches users who historically churned. The score updates daily.
This is a behavioral model, not a predictive model in the statistical sense. We are not claiming a specific accuracy percentage for your product. The score reflects the behavioral state of a user relative to patterns in your own workspace data. It gets more useful as your event volume grows and as you configure milestones that reflect your actual activation definition.
The model weighs a combination of signals across three dimensions:
You will see each user's score in the Users list view and in their profile. The score is displayed as a number and as a risk band: Low (0-29), Medium (30-59), High (60-79), and Critical (80-100). The risk band thresholds are configurable under Settings > Scoring if the defaults do not map well to your product's churn curve.
The score alone does not tell you why a user is at risk. Pair it with the Activation timeline on the user's profile to see which milestones they completed, which they did not, and when their engagement started to decline. That combination usually gives enough context to decide what nudge or human outreach makes sense.
The churn model does not incorporate billing or payment data (unless you send those as events). It does not factor in support ticket history, NPS responses, or external CRM data. It is scoped to behavioral signals from your product instrumentation. For products where churn is driven by billing events or external relationship factors rather than in-product behavior, the score will be less diagnostic and should be treated as one input among several rather than a primary signal.
The Nudge editor lets you create three types of in-app elements: checklists, tooltips, and banners. Each nudge has a display condition that controls when it fires, and a target audience that controls who sees it. All of this is configured in the editor with no code changes needed after the initial SDK install.
Each nudge requires at least one trigger condition. You can combine conditions with AND logic:
Target nudges to a specific user segment by filtering on identify traits (plan tier, company size, signup cohort) or milestone completion status. A typical setup might be: show the "Connect your data source" checklist only to users on the Growth plan who have not yet completed the first milestone within 3 days of signup.
Each nudge has a frequency cap (default: show once per user, never repeat). You can change this to once per session, once per N days, or always. Suppression rules let you hide a nudge from users who dismissed it, completed the target milestone, or are already seeing another nudge from a higher-priority campaign. Managing overlapping nudges is the most common source of user-experience problems, so review the active nudge list before launching a new one.
The Onboardvue REST API lets you ingest events from server-side code, query user scores programmatically, and configure webhook delivery. All endpoints are served from https://api.onboardvue.com. The API uses JSON for request and response bodies.
Pass your secret API key in the Authorization header as a Bearer token. Your secret key is different from the frontend write key. Find it under Settings > API keys in your workspace. Keep secret keys out of client-side code.
Authorization: Bearer sk_live_xxxxxxxxxxxxxxxx Content-Type: application/json
Ingest a single event from server-side code. Equivalent to a track() call from the JS SDK. Use this for backend actions that do not happen in the browser: subscription upgrades, API-triggered workflows, webhook-received events from third-party services.
// Request POST /v1/events { "userId": "usr_8a4f2c", "event": "Integration Connected", "properties": { "integration": "salesforce", "source": "oauth_flow" }, "timestamp": "2026-06-10T14:22:00Z" } // Response 200 { "ok": true, "eventId": "evt_3b9d1e" }
Returns the current churn risk score and activation status for a given user. Useful for routing decisions in your own backend: for example, triggering a Slack alert to your CS team when a user's score crosses 70.
// Request GET /v1/users/usr_8a4f2c/score // Response 200 { "userId": "usr_8a4f2c", "churnScore": 42, "riskBand": "medium", "activated": false, "milestonesHit": 2, "milestoneTotal": 4, "scoreUpdatedAt": "2026-06-28T00:00:00Z" }
Configure webhooks under Settings > Webhooks to receive real-time HTTP POST callbacks when specific conditions are met. Supported events:
user.activated: fires when a user completes your activation gateuser.churn_risk_high: fires when a user's score first crosses the High threshold (default 60)user.churn_risk_critical: fires when a user's score first crosses the Critical threshold (default 80)milestone.completed: fires on each milestone completionWebhook payloads are signed with an HMAC-SHA256 signature using your webhook secret (passed in the X-Onboardvue-Signature header). Verify this signature before processing any payload. Retries: up to 3 attempts with exponential backoff on non-2xx responses.
The events ingestion endpoint is rate-limited at 1,000 requests per minute per workspace. The score and user endpoints are limited at 200 requests per minute. If you need higher limits for a specific use case, contact us at [email protected].
Email us at [email protected] and we will help you get set up. Response time is typically under 4 hours on business days.