Implementation worksheet · 7 min read
A first-month rollout plan for in-app onboarding
Spend week one on plumbing and internal users: SDK installed behind a flag, identity and one value event verified, stable attributes on every target. In week two, show one flow to a slice of new signups with a holdout kept aside. In week three, widen that flow and add a checklist only if week two's gate passed. In week four, review the result against the metric you declared on day one. Every week ends with a gate that can stop the plan, such as broken targets, a performance regression, a focus or keyboard failure, or a missing exposure log. One flow measured properly in a month is worth more than five flows nobody can evaluate.
An onboarding rollout can fail quietly: flows ship, dashboards fill, and a month later nobody can say whether anything improved or which piece did what. This plan is for a product team adopting in-app onboarding for the first time, with one product manager and part of an engineer's time. Boundary: new signups on the web app, the first thirty days after the SDK goes in. Email and lifecycle campaigns are out of scope.
Put it into practice
1. Days 1-2: declare the metric, the holdout and the window
One value event with a written definition, such as a first shared project within seven days of signup. A holdout share (15% in the worked example) that stays on no-guidance for the whole month. The review date, and any extension rule. Writing these first is what makes week four a review rather than a search for good news.
2. Week 1: install, identify and verify one event
SDK behind a feature flag, visible to internal users only. Confirm the identify call carries only the attributes your targeting needs, the value event fires once per real completion, and every element a flow will point at has a stable data attribute in the markup.
3. Week 1 gate: the plumbing checks
Measure page performance with and without the SDK against your budget. Confirm exposure events are logged at the moment a user can see a flow. Run your release acceptance checklist. If any check fails, week two waits; a slipped week costs less than a month of unreadable data.
4. Week 2: one flow, a slice of signups, holdout on
Show the welcome tour to a quarter of non-holdout signups. Run the keyboard and focus restoration checks against production, not only staging. Put the dismissal and opt-out policy live on day one of the flow, not after the first complaint.
5. Week 2 gate: behavior in production
Targets resolving, dismissal rate, support contacts that mention the tour, focus landing where the test plan says. Decide the stop conditions before the week starts, for example any target failing to resolve for a day, so stopping is a rule rather than a debate.
6. Week 3: widen, then add one piece at most
Show the tour to all non-holdout signups. Add the setup checklist only if the week two gate passed. Adding it means the month now measures tour plus checklist against no guidance; say so in the review, or give the checklist its own holdout. Don't edit the tour mid-window.
7. Week 4: review against the declared metric and decide
Compare everyone assigned to guidance with the holdout, from each user's assignment date, and report the difference with its interval. Keep, change or remove, written down with the evidence. Then plan month two from what you learned, including what to retire.
First-month rollout worksheet
Copy this structure into your review document and record your observed result for each row.
| When | Scope | Gate to pass | Illustrative status |
|---|---|---|---|
| Days 1-2 | Metric, holdout and window declared | Written and dated before install | Declared: first shared project in 7 days; 15% holdout |
| Week 1 | SDK behind a flag, internal users only | Identity and value event verified | Passed after one duplicate event was fixed |
| Week 1 | Stable attributes on 8 targets | Attributes in markup and reviewed | Passed |
| Week 1 | Performance with and without the SDK | Within the agreed budget | Passed |
| Week 2 | Welcome tour to a quarter of non-holdout signups | No target failures for 3 days | Failed on day 2; selector fixed; gate restarted |
| Week 2 | Keyboard and focus checks in production | Focus lands as the test plan says | Passed |
| Week 3 | Tour for all non-holdout signups | Exposure log complete | Passed |
| Week 3 | Setup checklist added | Only if the week 2 gate passed | Added on day 17 |
| Week 4 | Review against the declared metric | Window extended only under the day-1 rule | Interval spans zero; declared 2-week extension used |
A failure worth checking
Five flows in week one. The team installs the SDK on Monday and by Friday has shipped a welcome tour, a checklist, three feature tips and a survey. By week four activation has risen, there's no holdout, two tips point at a button renamed in week two, and the survey opened on top of the tour for a third of new signups. Nobody can say which piece helped, which hurt, or whether the rise was seasonal, and month two starts with the same question month one should have answered.
Common questions
Why only one flow in the first two weeks?
Because the first flow tests the plumbing as much as the content: identity, targeting, selectors, exposure logging and performance. Finding a broken piece with one flow running is cheap. Finding it with five running means debugging interactions instead of the problem.
What if we can't afford a holdout?
A holdout of new signups gives up the flow's benefit for a slice of users for a few weeks. If that's unacceptable, make it temporary: hold out a share of signups for two weeks only, keep each held-out user away from the flow for their own 7-day measurement window, and compare signups from those two weeks. It's less precise than a month-long holdout and much better than before-and-after.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.