Cross-device memory
Frequency that follows the user, not the browser. Once someone is known, what they've seen and dismissed carries across their devices — so they never get the same guide twice on their phone after seeing it on their laptop.
Tied to the user
History follows an identified user, not a single browser.
No repeats across devices
Seen it on desktop? It won't reappear on mobile.
A seamless experience
Onboarding picks up wherever they left off.
Live in three steps.
Identify your users
Tell Wakeline who the user is.
They switch devices
Phone, laptop, anywhere.
No repeats
Their guide history travels with them.
The welcome tour that does not follow you to your phone.
A user finishes your tour on the office laptop, opens the app on their phone that evening, and gets the same welcome again — unless seen-state lives with the user. Here is the setup that prevents it.
Identify on every platform
Web and mobile both call identify() with the same user ID after login. Same ID, same person, same memory — that is the entire contract.
Ship the tour normally
The activation tour runs with frequency "until completed". Nothing about the flow itself is device-aware; the state layer handles it.
Complete once, done everywhere
The user finishes on the laptop. The completion is recorded against the user, so the phone, the tablet, and next year's new laptop all know.
Same for dismissals
Don't-show-again on one device is don't-show-again on all of them. An opt-out that resets per browser is not an opt-out — it is a delay.
What to expect: Guides feel like product memory instead of browser cookies. The metric that moves: repeat impressions of completed guides drop to zero for identified users.
When not to use cross-device memory.
No pattern fits every job. Here’s where we’d point you at something else — sometimes ours, sometimes not.
Anonymous-only surfaces
Before identify(), state is per browser — that is physics, not policy. On public pages, design guides assuming no memory: single-shot banners and page-scoped tips, not multi-session sequences.
Shared logins
If five agents share one support account, they share one memory — the first person to finish the tour finishes it for everyone. The fix is real per-seat accounts, not guide configuration.
Deliberate re-showing
Sometimes you want repetition — a compliance notice each quarter. Use a new guide per cycle (or every-visit frequency) rather than fighting the memory that is protecting users the rest of the time.
What exactly carries across devices?
Per-guide state for identified users: seen, completed, dismissed, don't-show-again, and checklist progress. Log in anywhere and your history applies — a tour completed on desktop will not replay on mobile.
What about before a user logs in?
Anonymous visitors get per-browser memory (so frequency caps still work), which merges into their identity once identify() runs. From that moment, state follows the user.
Do I need any special code?
Just consistent identify() calls: the same stable user ID on every platform where Wakeline runs. Use your database ID, not an email that might change casing between systems.
Does this apply to surveys too?
Yes — answered once is answered everywhere, which protects response quality: nobody pads your NPS by being asked on three devices.
What if two people share a computer?
State follows the login, not the machine. When user A signs out and user B signs in, identify() switches the identity and each sees their own guide history — A's completed tour stays completed for A, and B starts fresh. The shared browser only matters for anonymous visitors.
See it on your own app.
Ship your first guide in minutes. Free to start — no credit card.