Explore / Chiku — first post-launch read

168/169 searches returned empty. Boston→NYC (9 searches) returning zero is not a real-world result. This is an integration/config bug, not genuine no-service.

Amplitude now points at the cause: the origin never resolves. On labs Search Submitted the destination resolves to a Wanderu city ID 100% of the time (48/48) but the origin resolves 0% (0/48); on destination_selected only 3 of 160 carried a resolved origin_wcityid, and nearest-hub substitution fired on just 30/160. Origins arrive as raw free text ("700 Atlantic Ave", "Tucson", "Berlin, Germany"). Leading hypothesis: the trip search runs without a resolved origin station → /api/trips returns nothing. See the Amplitude tab.

• Start at origin resolution — why is the origin free text / lat-lng at search time instead of a Wanderu city, and why does nearest-hub substitution only fire ~19% of the time?
• The one success (Chicago→Detroit, 5 trips) is the control case — both major hubs; diff a working call against a failing one.
• Parallel signal: /search (pservs) failed all 7 carriers on Boston→NYC and only ran from dev pods (VPN/VPC). Determine whether Explore shares that infra dependency.

Until this is fixed, no future check-in can report conversion. Must move before 2026-06-10.

The Amplitude funnel exists (destinations_suggested → destination_selected → Search Submitted) but can't yet reach conversion. Per the data dictionary, search outcome (result count, success/failure) lives in Datadog by design — so don't duplicate it into Amplitude. Instead, connect the two:

• Join key — propagate a search / conversation ID from the Amplitude funnel through the Datadog /api/trips outcome to booking, so "search → results → trip clicked → checkout" is answerable across systems. (Refines the Round 1 conversation-ID ask.)
• Resolved-origin signal — add depart_wcityid or an origin_resolved boolean to Search Submitted / destination_selected so the origin-resolution gap shows up in the Amplitude funnel itself.
• Mind the window — Search Submitted only began firing Jun 4; the Amplitude search funnel is ~4 days deep until it matures.

This is the measurement spine for the whole check-in cadence.

Only 16 destinations ever appear because they come from a fixed seed list, while origins sprawl (60 distinct). A user from Tucson, Omaha, or Hattiesburg gets NE-corridor suggestions that may have no service from where they are — which also feeds the zero-result problem. Inspiration value collapses when the answer is the same 16 cities for everyone.

• Generate destination candidates dynamically from the origin's actual reachable network, not a global seed list.

Lots of users are looking for specific dates or trying other dates — and the surface is largely ignoring them. 158 of 160 destination picks (99%) ran on date_source: "default — 2 weeks out" with date_confidence: "low" — only 2 used anything else. Meanwhile the prompts are full of date intent: "august 24-27", "Cheap from dc today", "LA to Atlanta July 12", "Check dates around June 14-16", "The date doesn't have to be the 21", "a weekend in july", "Any date will work".

Two distinct fixes:

• Extract & honor explicit dates — "today", "tomorrow", "July 12", "august 24-27" should set the search date instead of falling through to the 2-week default.
• Support flexible / window dates — "in August", "a weekend in july", "any date", "cheapest day" → a date-range / cheapest-day search rather than collapsing to one day. This is Pattern A (flexible dates, fixed destination) — the largest scenario cluster — and answers Round 1 KU #1 (date certainty).

Independent of the zero-result bug: even when a search returns trips, a defaulted low-confidence date means it's not the trip the user asked for.

Repeat, specific, answerable from data we already have (places/stations). "Where will it stop in DC", "closest stop to Long Island." Likely a straightforward Chiku capability + tool call.

One user rephrased the rail question 4× — an unambiguous UX-failure signal that Chiku isn't answering it. Either give Chiku Amtrak routing/data or have it state clearly what it can and can't do for rail. Silent failure is the worst outcome.

Stakeholder desire to bring motion to the explore surface. Not evidence-backed by this check-in and lower priority than the search / origin-resolution work — but two placements would pull double duty as UX and perceived-performance wins, so worth scoping:

• Chiku "thinking" state — average response is 1.9s but worst case is 6.1s. A motion treatment on the wait directly improves perceived latency on the slowest turns.
• Destination reveal — animating pins/cards as Chiku surfaces them (destinations_suggested, 293 in 30d) reinforces the "surprise me" moment, the core of the inspiration loop.

Needs scoping: which animation, where, and a motion spec aligned to the design tokens (duration.fast 100ms / duration.normal 150ms; respect prefers-reduced-motion). Keep it behind the P0/P1 work — don't let polish jump the queue while searches still return nothing.

• Misdirected support (lost-passenger, refunds — "where is my bus") lands on Chiku with no escape. Add detection + a handoff to real support.
• Off-network / international (~10): Chiku should clearly state Wanderu's coverage boundary instead of improvising.

"Just give me the options like old pen I don't wanna see the ai." Only ~7 messages — don't over-rotate — but it speaks directly to the chat-primary vs. structured-browse question in the LLM-integration doc. Cheap mitigation: a visible escape hatch to a plain map/list view. Log how often it's used; it's a data point for the build-vs-paradigm decision, not a fire to fight.

The constraint_edited interaction fired exactly once in 30 days, against 160 destination picks and 326 prompts. The affordance to edit origin/destination chips is effectively undiscovered. Either users don't need it (they re-prompt instead) or it's invisible. Worth a quick design look — but lower stakes than the search and origin-resolution work.

The labs surface migrated to canonical event names ~Jun 1–2. Confirm the three legacy emitters are fully removed:

• Chiku Message Sent → superseded by LLM Prompted.
• Chiku Destinations Lit → superseded by Explore Page Interacted [destinations_suggested] ("Lit" was UI-mechanism naming, an anti-pattern).
• Inspiration Origin Detect Failed → a failure event that belongs in Datadog, not Amplitude. Verify /api/whereami failures are captured in Datadog instead.

All three last fired Jun 1 with the dead page_type: "inspiration_base", so this is likely confirm-and-close — but worth verifying so dashboards don't double-count.