Learning from Human Behavior: Amplitude’s Feedback Loop for AI Products

From voice recognition to product analytics

Sonalight let people hear text messages and dictate replies without handling a phone. But its founders, Spencer and Curtis, encountered a capability problem: success required substantially better voice recognition. As Jeffrey Wang recounts, they were software engineers without a machine-learning background and did not want to spend years solving that underlying problem.

Their effort to understand why users left or stayed produced internal analytics tools that other companies in their YC batch wanted. That demand prompted the pivot to Amplitude. Jeffrey joined through mutual contacts, bringing a distributed-systems and analytics background. Gaming companies and founders from companies such as Zynga became important early customers: they already valued rigorous measurement of engagement.

In this Latent Space conversation, published June 8, 2023, Jeffrey introduced himself as Amplitude’s co-founder and chief architect, and Joe Reeve as the lead for its AI research and development. The company’s underlying problem remained the same: digital products generate detailed evidence of how people use them, but internet-scale volumes exceed what people can readily interpret. Jeffrey’s ambition was to reduce the manual work between observing behavior and improving a product.

One question becomes seven model decisions

Amplitude approached AI both as a product builder and as a supplier to other builders. Developing its own features could expose the problems customers would encounter. Jeffrey described three places to look for useful applications: - Collaboration touchpoints: let a machine take one side of an existing human handoff. - Interface friction: suggest values or complete repetitive selections inside existing controls. - Supplementary tools: provide a separate AI interface for related work. For Amplitude, these opportunities spanned collecting standardized, queryable data and helping people analyze it.

Its first large language model (LLM) product effort was question-to-chart: enter a natural-language question and receive a chart. Asking for the entire chart and query in one request produced hallucinations and failures to recall information still inside the context window. The team split generation into seven narrower questions, including which events to use, how to display the result, and what to name it.

That decomposition created a monitoring problem. A bad chart could reflect one failed decision or several; an invented value could cause an enum mismatch in application code. Amplitude instrumented individual model calls and groups of calls to track failure frequency, reasons, and retries. The completed chart was the user’s result; a single model call could be the place to diagnose its failure.

At recording time, question-to-chart had begun rolling out to signed-up AI design partners the previous week. Amplitude already used predictive machine learning for content relevance and decisions about upgrade or app-rating prompts. Traditional models also helped narrow the candidates passed to the LLM, leaving it more specific context for the remaining decisions.

Measure what happens after generation

A thumbs-down cannot identify which of seven decisions failed. Some builders also hesitated to add rating controls because they implied a process for improving results that the team did not yet have. Even after revising a prompt, the practical question remained: did the change help?

Behavioral feedback extends measurement beyond ratings: do people use, share, or discard the generated content? Amplitude planned to compare prompt templates through A/B tests—testing revised prompts against a control using errors, ratings, and behavior. That integration was planned, not yet in use.

Copy generation offered a small-scale example of a self-improving product. An unnamed customer had used manually written variants with a multi-armed-bandit-style system, which adapted toward the best-performing alternative. A participant described an internal hackathon prototype built roughly two months earlier that replaced manual copywriting with an LLM continually generating new variants. The bandit selected among them; no measured performance improvement was reported.

The broader proposal combines an editable product structure, generated alternatives, and experiments that select what works. In a hypothetical news reader, a human defines the purpose while the system varies titles, section descriptions, and navigation. Generation supplies candidate changes; A/B tests or bandits provide the selection mechanism.

Use language to start, controls to refine

Natural language makes analysis approachable when users do not know the data or which questions to ask. Precision becomes harder once they know exactly what they want. SQL and code can express choices more precisely, while a model cannot recover exact meaning that ambiguous wording never supplied. A revenue total illustrates the stakes: the calculation’s underlying definitions can materially change the result.

One proposed interface embeds model suggestions in editable analytics controls. The model proposes a field value; the user inspects and refines it. The same principle applies while work runs: expose individual actions and let users tweak, stop, or retry them. AutoGPT provided an example of the opposite experience—an opaque process that could keep consuming paid tokens.

Success measures also need to reflect the product’s purpose. A North Star metric, the main measure guiding product improvement, should correlate with business outcomes. Time in app may suit social media; successful searches and return usage may better serve search. The recommendation was to evaluate LLM features against existing goals such as conversions and customer value, using A/B tests to connect the feature to those outcomes.

A related design rule constrains at least one side of the interaction: - Narrow input, broad output: buttons or toggles provide predictable inputs while the model has room to generate. - Broad input, narrow output: free-form text produces a constrained result the application can validate. Open-ended chat expands both spaces. The discussion treats this as especially difficult when a company adds chat to a product whose core purpose is something else, such as analytics.

Edits reveal which decision needed repair

GitHub Copilot supplied a concrete comparison. Citing the Copilot-Explorer telemetry writeup, a participant described checks on whether accepted code remained after 30 seconds and at minute intervals through five minutes. That retention curve measures how long suggestions survive actual use, extending evaluation beyond initial acceptance.

Amplitude found a similar opportunity in its instrumented chart builder. Linking a generated chart to its originating model workflow also linked subsequent parameter edits to that generation. Changing a metric or removing an event could reveal which decision needed correction. Ordinary product use therefore supplied more detailed feedback than a rating, although the team did not report a resulting model-training improvement.

Explore broadly, specialize repeated tasks

General models helped the team explore quickly. Smaller models obtained from Hugging Face ran internally on specific tasks, including selecting values before passing them to a general model. These smaller models were explicitly not fine-tuned. Cost and latency motivated further specialization.

Event selection shows why. A new Amplitude user might face roughly a thousand event names of uneven quality, with little knowledge of how colleagues configured them. Asking an OpenAI model to match intent to an event worked reasonably well, according to the team, but repeating the request was slow and expensive.

After validating the idea, the team switched to embeddings, vector representations used to match similar items. Computing them across the event database required upfront engineering, with the aim of lowering recurring cost and latency while preserving reasonable quality. Embeddings also provided a degree of similarity: the speaker found LLM-generated rankings useful but found it harder to get meaningful numerical match strengths from the model. No measured comparison accompanied these observations.

Modeling behavior requires distinctive data

The next ambition was to model behavior itself. Product interactions are specific: how people use Square Cash, its wallet, or checkout cannot simply be sourced elsewhere. The argument acknowledged model innovation while locating further application opportunities in distinctive behavioral datasets.

The proposed large behavioral model drew inspiration from language models learning abstractions from examples. Could training on product behavior produce useful abstractions about users and outcomes? This was a research thesis for a system fundamentally different from an LLM. The expectation that such datasets would grow more important as rapid model evolution tapered was a forecast, not a demonstrated result.

Privacy imposed practical boundaries. Participants described stripping personally identifiable information (PII) from model inputs and training data, including unexpected free text such as email lists pasted into charts. Experiments detected and removed that content, using replacement tokens so the LLM could continue operating. The training under discussion was described as internal and excluding private data and PII. A question about informing users of training received no specific notification or consent policy.

Analysis across time still needs a way to connect events: without an identifier, an analyst cannot tell whether an earlier visitor later purchased. The proposed balance was pseudonymized first-party data, retaining identifiers needed to connect a user’s activity across time. Amplitude’s stated approach also excluded selling behavioral data or combining activity across unrelated sites.

Creativity, capability growth, and a long horizon

The lightning round turned to surprises. One participant recalled a model solving an Olympiad problem they had been unable to solve during their competitive-math years, prompting speculation that creativity might be less complex than people assume. The paper, model, and evaluation conditions were unspecified. Another participant found developers’ rapid adoption of internet-connected systems such as AutoGPT predictable—and was connecting such systems themselves.

Whether capabilities would keep improving at the same pace or plateau remained a strategically important uncertainty: startup plans and pivot decisions depended on it. A separate question challenged shifting definitions of intelligence—why achievements such as chess, image creation, and writing seem to lose their status as evidence of intelligence once machines perform them.

Speculation about biological computing followed. One participant recalled an unidentified report of brain tissue trained to play tic-tac-toe; another cited roughly 30 watts for the human brain when discussing energy efficiency. Neither supplied the experimental details or comparable workloads needed for a technical comparison with language models.

Before audience questions, the closing advice returned to product building: it is still early, despite the speed of developments, and the implications will unfold over a long horizon. Design machines to help humans do their work well, with each contributing what it does best.

Audience Q&A: inference transactions and taxonomy search

Audience questions returned to question-to-chart’s implementation. It generated definitions for Amplitude’s custom query engine, rather than SQL. Narrow tasks—selecting chart type, metrics, events, properties, and a name—made it easier to supply relevant examples. The team reported better output from these focused prompts than from requesting an entire chart definition at once.

After finding LangChain useful for prototyping but restrictive for this implementation, the team built a small TypeScript wrapper. Its inference transaction grouped model calls for monitoring both the complete request and each call. Developers used ordinary await expressions and switch branches to obtain a chart-type decision and run the corresponding queries.

All chatbot calls then used GPT-3.5 Turbo, although the wrapper supported different models per inference. The team was considering DaVinci, GPT-4, and internal models for different prompts, and potentially bundling text and image generation. It also wanted an internal-model fallback for customers prohibiting data transfers to OpenAI; that was a desired capability, not a confirmed deployment.

For embedding similarity search, the team had used plain Postgres in production for months before adopting pgvector. The relevant scale was limited: the feature had not reached all customers and received relatively little traffic. Amplitude also used other storage systems.

The vectors represented event taxonomies—the vocabulary of possible events—rather than individual users or every event occurrence. A hypothetical DoorDash taxonomy included browsing, adding to cart, checkout, and purchase. The speaker put taxonomy scale at tens of millions and said Postgres handled it; embedding trillions of event occurrences would require a different assessment.

A participant also proposed separating taxonomy knowledge from underlying customer data: a query generator could know which events exist without accessing their contents. This was suggested as a way to reduce prompt-injection exposure, not as a security guarantee.

The final ambition: explain behavior with less manual instrumentation

The final audience question asked what a behavioral model might do. Amplitude’s existing predictions feature used the previous 90 days of behavior to predict membership in a future cohort—a customer-defined group such as people who churn, purchase, or upgrade. The hope was that a model learning behavioral sequences could improve those predictions, then go further: discover groups with different likely outcomes and explain what separates them.

That ambition returned to a familiar customer question: why did some users return the next day while others did not? Amplitude used heuristics to investigate. A behavioral model might offer more interpretable assessments of causal impact, but separating causation from correlation remained difficult, noisy, and computationally intensive. Prediction and causal explanation were distinct ambitions.

The last possibility was reducing manual instrumentation: customers then had to choose meaningful clicks and page views and assign event names. Automatically recording sessions and browser activity could produce data too noisy to interpret usefully. A behavioral model might eventually make that activity understandable enough to answer product questions without manual instrumentation. The speaker explicitly doubted whether this was possible, leaving the conversation at a concrete engineering boundary: turning recorded activity into meaningful behavior.