Onboarding — Baseline Performance Data

Purpose

The strategy writer currently sets goals (metric, targetValue, timeframeMonths) by reasoning from the client context file alone. Without real numbers, Claude invents plausible-sounding targets that may be unrealistic or meaningless. Capturing a baseline at onboarding gives the strategy document grounded, client-specific goals.

Phase 1 — Manual Entry (Live)

A new “Baseline” step in the onboarding wizard (Step 3, between Documents and Launch) presents a progressive disclosure form. Three sections are gated by yes/no toggles:

1. Website & SEO    → do you have a website?
2. Paid Advertising → do you run ads?
3. Social Media     → do you have social media?

Each section reveals platform selectors and metric fields relevant to that category. All fields are optional — the user can skip any section or the whole step. The data is stored in the TenantBaseline table and injected into the strategy-writer prompt as a “CURRENT PERFORMANCE BASELINE” section.

Fields captured

Website & SEO

Paid Advertising (per platform: Google Ads / Meta Ads / LinkedIn Ads)

Social Media (per platform: LinkedIn / Facebook / Instagram / Google Business Profile)

General

DB model

TenantBaseline — one row per tenant, upserted on save. adMetrics and socialMetrics are JSONB columns keyed by platform slug. The source field will be "manual" in Phase 1 and "connected" in Phase 2 when auto-filled from a channel.

Strategy prompt injection

buildStrategyPrompt() in strategy-writer.worker.ts fetches TenantBaseline before building the prompt. If a baseline exists, it is appended as a markdown section:

CURRENT PERFORMANCE BASELINE (use to set realistic, grounded targets):
- Monthly website visitors: 3,200
- Monthly organic clicks: 820
- Current CPL (Google Ads): ₹2,100
- LinkedIn followers: 1,450
...

The system prompt instructs Claude: “Where baseline data is provided, anchor all KPI targets to it. Express targets as deltas (e.g. +40% from 820 → 1,150 clicks/month).”

Phase 2 — Channel Auto-fill [To Build]

Add a “Connect to auto-fill” button per section. Clicking it initiates the OAuth flow for the relevant channel (GSC for website, Google Ads for ads, etc.) and returns the user to the onboarding step after the callback.

Key design decisions for Phase 2

OAuth redirect handling The OAuth callbacks currently redirect to /settings/channels. In Phase 2 they need to accept a ?return=onboarding param and redirect back to the wizard at the correct step. Each callback (GSC, Google Ads, Meta, LinkedIn) needs this parameter handled.

Async data fetch After a channel connects, the relevant insight worker must run before fields can be pre-filled. The UX needs:

• “Fetching your data…” loading state (poll every 3s, max 60s)
• Fallback to manual entry if fetch times out
• source: "connected" written to the baseline so the strategy writer knows the data is authoritative

New businesses with no data Connecting GSC for a brand-new site returns zeros or empty data. The pre-fill logic must distinguish “no data yet” from “failed to fetch” and show “No data found — enter manually” rather than 0s.

LinkedIn dual-role LinkedIn serves both Ads and Social. Connecting it once should satisfy both sections. The platform selector should mark LinkedIn as already-connected across both sections once the OAuth is complete.

Platforms per section

Future: Baseline Refresh

Once channel connections are live, baseline data can be re-fetched monthly (via the existing insight workers) and stored as a new TenantBaseline snapshot. The strategy revision flow can then compare baseline at time of strategy creation vs. current performance to measure progress.