Diagnosing a Stalled Funnel from Server-side Data

By Stanley · Founder, Piaopiao Travel · First published 2026-10-28 · Updated 2026-10-31

Correction, October 31: The first version said the cause of the first 28 days of the freeze was unknown. It has since been found to be the same cause as the last 27 days.

Question

Sign-ups for Piaopiao Travel, a Chinese-language AI travel assistant, stopped for 55 days from August 27. The site had no page analytics. What can the server-side database alone explain, what can it not, and what should be done first?

Basis

• Data. 16 aggregate queries on the production database, each run inside a read-only transaction, with no row-level personal data pulled. Snapshot: 2026-10-28 06:45 UTC.
• Conventions. Timestamps truncated in UTC. Account deletion is a hard delete, so every historical figure covers surviving accounts only. October is a partial month.
• Definitions. AI calls are signed-in chat requests charged against quota; anonymous visitors are not stored. Leads are raw inquiry-form submissions, neither deduplicated nor bot-filtered. AI counting starts mid-July, and leads moved into our own database in mid-July, so neither series covers May or June.
• Labels. Only a cause backed by evidence is called confirmed; a hypothesis the evidence contradicts is marked ruled out. Everything else is a hypothesis, stated with its counter-evidence and the test that could disprove it.
• Publishing rule. Only shares, relative shapes and durations appear here; absolute operating counts do not.

Findings

The shape. June was the peak month for sign-ups; July and August ran lower but steady; September had none. 93% of all recorded AI calls fell in July and August, and by September AI use was under a tenth of August's level. Inquiry leads did not stop: September's volume was above August's.

Thread 1: the sign-up path broke.

• Confirmed: an SMS outage. The SMS provider suspended the account for an unpaid balance, and verification codes stopped going out. Sign-up required an SMS code, so for all 55 days, from August 27 to October 21, nobody could register. Evidence: sign-ups went from some every day to zero on August 27, a sudden stop rather than a decline, and that day matches the suspension, as confirmed by the founder. Every verification send in the surviving logs failed; earlier logs were lost in a September 23 service restart. A sign-up path that does not depend on SMS went live on October 21, and SMS was restored on October 28. Since then, new sign-ups have reappeared and completed verification.
• Ruled out, hypothesis A1: the freeze was a drop in acquisition. Leads kept arriving over the same period, and September brought more than August. Acquisition did not stop; the sign-up path did. Leads are not deduplicated, so this rests on the relative trend only.
• Hypothesis A2: sign-ups stayed low after the fix. In the week after the fix, sign-ups ran at about a third of August's weekly rate. Either acquisition fell or the new flow adds friction; the data cannot yet separate the two.
• Detection lag. Both the zero-sign-up streak and the outage went unnoticed for 53 days, until a routine check. No alert fired: monitoring only checked that the service responded, counted even authentication-error responses as healthy, and could not see a business-level failure like SMS.

Thread 2: activation concentrated in a few users.

• About a third of registered accounts (36%) have ever used the AI. The top 5 users account for 41% of AI calls; one admin alone accounts for 19%.
• Retention features (saved trips, traveler profiles, invite codes, passkeys) are each used by only a handful of accounts. A passport-expiry field added in September has never been filled in.
• Hypothesis B1: the September AI drop is a mechanical result of the sign-up freeze, if usage clusters soon after registration.
• Hypothesis B2: product problems drove existing users away. On August 28, mobile itinerary generation was found to fail every time (94–95 s on the server, past iOS's roughly 60 s request timeout); it was fixed the same day. A new chat engine shipped on September 1.
• Against strong concentration: only about one in five AI users tried it just once. B1 and B2 can be separated by a cohort query on existing data (days from registration to each AI call); it has not been run yet.

Thread 3: the lead loop is not closed.

• More than 98% of inquiry submissions never left status "new". None is marked "contacted". Leads record a creation time but not when the status changed.
• The records do not show whether alerts were delivered, whether anyone followed up outside the system, or whether there was an agreed response time and owner. So "status never changed" is not the same as "nobody followed up".
• Hypothesis C1: the value of these leads was never realized. Test: check the alert channel and operator records for leads actually contacted.

Decision

Ranked from lowest effort and most certain return to highest effort and least certain:

Page analytics went live on October 28. Two weeks of data can overturn the hypotheses: for A2, if visitors are substantial but sign-ups stay low, the problem is conversion and action 3 becomes "fix the sign-up flow"; if the cohort query shows August's usage came mainly from earlier sign-ups, B1 falls; if most leads were followed up outside the system, C1 shrinks to a recording problem; if deduplication shrinks recent leads sharply, A1's ruling-out has to be revisited.

Limits

• Log gap. Server logs from before September 23 were lost in a service restart, so logs cover only the second half of the freeze.
• Signed-in users only. Anonymous chats are not stored, and AI counting starts mid-July, so earlier usage by May–June sign-ups (just over half of all accounts) is invisible.
• Short session history. Session records are kept only briefly, so there is no 30-day session-based activity measure, and the automatic sign-in at registration is not recorded as a login.
• Raw leads. Lead counts are not deduplicated or bot-filtered; shares built on them are upper bounds on real demand.
• Status timing. Response time cannot be measured until a status-change timestamp exists.

Source: read-only aggregate inventory of the production database (2026-10-28 snapshot), plus the project's site-check, incident, change and release records.