Wire Onboarding and Growth
Connect Wire for onboarding, lifecycle measurement, experiments, and the product learning loop.
Wire onboarding and growth
Wire is the default ordinary-event destination in the AI Pro and Standard development branches. Initialization uses it to define the activation event, lifecycle funnel, event map, first onboarding experiment, learning review, and optimization backlog. It does not promise an automatic optimizer, and it does not treat a selected setup mode as a connected account.
What the initializer plans
The generated docs/GROWTH.md contains:
- the buyer's activation event and growth hypothesis
- a lifecycle funnel from first open through repeat use
- existing event coverage and the instrumentation still required
- one controlled onboarding experiment
- the decision metric and first learning review
- an optimization backlog that preserves the static fallback
The generated docs/KEYS.md records Wire as required with one of these modes: mcp, manual, or later. skip is not valid for Wire.
Configuration contract
The app reads Wire configuration from one shared module. Two variables are required for a transport and one is optional:
| Variable | Meaning |
|---|---|
EXPO_PUBLIC_WIREAI_API_KEY | Authenticates the buyer's Wire tenant |
EXPO_PUBLIC_WIREAI_SERVER_URL | Selects the Wire server transport |
EXPO_PUBLIC_WIREAI_APP_ID | Namespaces the app; defaults to default when omitted |
Add real values to the local .env file. Do not put them in answers.json, docs/KEYS.md, logs, or git.
Runtime behavior
| State | What the app does | What you may claim |
|---|---|---|
| API key or server URL absent | getWireConfig() returns null; the onboarding route renders the built-in static questionnaire | Wire is pending or manually required |
| Complete transport present | The questionnaire route mounts WireOnboarding with buyer configuration | Wire is configured locally, not yet verified |
| Configured request fails | fallbackFlow renders the static questionnaire and the app logs the error | The core questionnaire path retained its fallback |
| Buyer workspace shows the expected event | The receipt can be recorded against the service | That specific event path is verified |
When the transport is complete, instrumented application events, screen views, onboarding events, auth outcomes, and purchase-funnel events use the shared Wire analytics instance. Firebase Analytics is not registered as an ordinary-event transport and does not become a fallback when Wire is absent.
The activation event entered during initialization is a planning decision. It does not create an event call site. During the matching feature task, add the event at the exact product action, route it through the shared analytics logger, and add a focused test before asking a tester to find it in Wire.
Crash reporting still goes to Crashlytics. Explicit Firebase collection controls and user-property calls remain direct Firebase operations. That separation lets Wire own the product learning loop without disabling the native Firebase services the app still uses.
The static questionnaire is the control path for the first experiment. A runtime fallback protects onboarding continuity, but it is not proof that analytics, flags, experiments, or a provider account are connected.
Connect manually
- Create or select the buyer's Wire workspace through the official Wire console.
- Add the API key and server URL to
.env; add an app id when the buyer needs a namespace other thandefault. - Run a native development build.
- Instrument the buyer-defined activation action during its feature task if the boilerplate does not already emit it.
- Complete onboarding and the instrumented product action.
- Confirm app-open, screen, onboarding, and activation events in the buyer workspace.
- Repeat one action and confirm the expected event count rather than an accidental duplicate.
- Remove one required Wire value, restart Metro, and confirm static onboarding remains available without Firebase event fallback.
- Record the non-secret receipt and update the service status.
Use a durable tester identifier that is safe for analytics. Do not use an email address, phone number, precise location, access token, or free-form health text as an event parameter.
Connect through MCP
Use MCP only when the active host lists a Wire connector. Ask it to perform the smallest scoped setup or verification action and retain the receipt. If the connector is absent or cannot complete the check, keep the status manual_required; do not convert an attempted call into connected by optimism. Optimism is not a transport protocol.
Run the first learning loop
- Keep the existing static onboarding as the control.
- Change one buyer-defined copy, order, or prompt variable in the variant.
- Measure onboarding completion, the activation event, and the selected success metric.
- Record the observation and decision in the learning review.
- Add only the next justified test to the optimization backlog.
The current workflow plans and measures this loop. It does not claim that Wire automatically rewrites the product from analytics.
Release boundary
Pending Wire credentials do not prevent planning, but release preflight treats required, unverified Wire setup as a blocker. A passing preflight still does not replace a real native build or a provider receipt.
Continue with Tool Integration for the other services, then First App Launch when every native prerequisite is ready.