Amplitude and CodeWords: behavioural cohorts that do something

Amplitude is very good at answering behavioural questions, and most organisations using it have a large collection of answered questions that changed nothing. The chart showed a problem, somebody screenshotted it, and the cohort of affected users stayed in Amplitude where nobody could act on them.

That is the gap worth automating. Not producing more analysis, but connecting the analysis that already exists to the systems where somebody can do something about it.

What we'll cover

• The gap between a chart and an action
• User properties, which make cohorts possible
• What the Amplitude APIs reach
• Connecting it to CodeWords
• Seven automations worth building
• Cohort activation, done properly
• Instrumentation that survives contact with analysis
• Accounts, not just users
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

The gap between a chart and an action

Four things stand between a finding and anything happening.

The cohort lives in Amplitude. The people who could act — support, sales, lifecycle marketing — work in other systems and cannot see it.

The finding is a moment, not a process. Somebody noticed in a meeting. Nobody is watching next month.

Nobody owns the follow-up. An analysis presented to a group is owned by nobody in it.

The behaviour is not visible where the customer is. A support agent talking to a frustrated customer cannot see that they hit the same failure four times yesterday.

Each of these is addressable, and none needs more analysis. They need the results delivered somewhere useful, on a schedule, addressed to a person.

User properties, which make cohorts possible

Behaviour alone rarely defines a useful cohort. "Users who did not complete setup" is broad; "users on the business plan who did not complete setup in their first week" is actionable, and the difference is properties your product knows and Amplitude does not.

Plan, account size, and industry turn a behavioural pattern into a commercial one.

Account age and lifecycle stage separate a new user struggling from a long-standing one who has changed behaviour.

Account health or support history identifies whether the behaviour is already known about elsewhere.

Keep them current. A property set at sign-up and never updated describes who somebody was, and cohorts built on it quietly stop being correct.

Send them from your systems on a schedule, since these attributes change outside the product and nothing in the product observes the change.

An automation keeping user properties in step with your own database is unglamorous and it is what makes every subsequent cohort worth building.

What the Amplitude APIs reach

Event ingestion accepts events from servers as well as clients, with user and event properties.

Identify sets user properties without sending a behavioural event, which is the right mechanism for the synchronisation above.

Group identify sets properties on accounts rather than individuals, which matters for anything business-to-business.

Behavioural cohorts can be listed and their membership retrieved, which is what activation depends on.

Chart and dashboard queries return the numbers behind saved charts.

Export retrieves raw events over a date range for warehouse loading or analysis.

Taxonomy endpoints cover the event and property schema on plans that include them, which is how conformance checking works.

Deletion endpoints handle privacy requests.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which cohort or chart, and what should happen to the people in it.
3. Authorize the connection with the appropriate API key and secret for the project.
4. Describe the exceptions: a cohort that has grown unexpectedly, a user who cannot be matched, a chart returning nothing.
5. Run it against a small cohort and inspect the result before anything reaches a customer.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Cohort activation. Membership delivered to the CRM, the support desk, or the messaging tool, so somebody can act. Covered in detail below.

User property synchronisation. Plan, account age, health, and support state kept current from your own systems, which is what makes cohorts meaningful.

Behavioural context for support. A customer's recent significant events surfaced on the ticket, so the agent knows what happened before they ask.

Tracking health monitoring. Events that have stopped arriving or whose volume has moved sharply, which is how broken instrumentation is noticed in days rather than months.

Scheduled findings with comparison. The chart somebody checks anyway, with the movement stated rather than the level.

Cohort change alerting. A cohort that grows sharply is a signal — a failing step, a broken release, a segment that has changed behaviour.

Group property synchronisation for business-to-business products, so account-level analysis reflects real account attributes.

Cohort activation, done properly

Send the cohort to where work happens. The CRM for sales follow-up, the support desk for proactive contact, the messaging tool for lifecycle communication. A cohort in Amplitude is an observation; the same cohort in a CRM is a task list.

Refresh it, do not snapshot it. Cohorts are defined by behaviour and membership changes. A one-off export is stale within a week and produces outreach to people who resolved the issue themselves.

Handle people leaving the cohort. Somebody who completed setup should stop receiving the nudge about not completing setup, and this is the part most implementations skip.

Cap the volume. An automation contacting everybody in a cohort of forty thousand is a campaign, and it should be treated with the review a campaign gets.

Respect contact preferences. A behavioural cohort is not consent, and membership does not override somebody's marketing preferences.

Measure whether it worked. A cohort activation with no measurement is an assumption, and the measurement is available in the same tool that generated the cohort.

Instrumentation that survives contact with analysis

A short list, because the analysis is only as good as what was tracked.

Track outcomes rather than interactions. "Report Exported" supports a question; "Export Button Clicked" supports a different and less useful one.

Put variation in properties, not in event names, or the event list becomes unnavigable within a year.

Identify users consistently across client and server, since a funnel spanning both breaks entirely without a shared identity.

Send server-side events for anything that must be accurate — payments, provisioning, background processing — since client-side tracking is incomplete by nature.

Write the definitions down, and check arriving events against them, or the taxonomy drifts as teams add events nobody else knows about.

Accounts, not just users

Most products sold to businesses are analysed as though they were sold to individuals, which produces conclusions that do not survive a sales conversation.

Group properties describe the account — plan, seat count, industry, renewal date — and they are set separately from user properties.

The unit of the question changes. "How many users adopted this feature" and "how many accounts have anybody using it" are different numbers with different implications, and the second is usually the one that matters commercially.

One power user is not adoption. An account where a single person uses a feature heavily looks identical in user-level analysis to one where the whole team has adopted it.

Churn happens at the account level, so anything predictive needs account-level behaviour rather than an average across its users.

Keep group properties current from your billing system, since plan and seat count change there and nothing in the product observes it.

For a business-to-business product, setting up group analytics properly is worth more than several months of additional event instrumentation.

Building it so it survives

Send an insert identifier with events so retries do not duplicate and distort funnels.

Match users on your internal identifier, not on email, since people change addresses and the same person appears twice otherwise.

Handle cohort pagination, since a large cohort is retrieved in pages and the first page is not the cohort.

Use export for bulk work rather than the query endpoints, which are built for charts.

Report the outcome. Cohort size, records updated, and anybody who could not be matched — the last figure usually reveals an identity problem worth fixing.

Limits worth knowing about

Query endpoints are rate limited and not intended for bulk retrieval.

Cohort membership is computed on a schedule, so a cohort is current as of its last computation rather than as of now.

Export has a maximum range per request, so wide backfills need chunking.

Historical event ingestion has a window, which constrains backfilling.

Some capabilities are plan-dependent, including parts of the taxonomy tooling, so confirm what your project includes before designing around it.

What to build first

User property synchronisation: plan, account age, and account health pushed from your own systems into Amplitude on a schedule. It is not glamorous, it takes little building, and every cohort anybody defines afterwards becomes more useful because it can combine behaviour with commercial reality.

Two habits make the difference. Update rather than set once, since properties captured at sign-up describe a person who no longer exists. And include the property that identifies internal and test accounts, because excluding them is the fastest improvement most analytics implementations can make.

Frequently asked questions

Why does our analysis never change anything?

Because the finding stays in the analytics tool. Deliver the cohort to where people work, on a refreshing basis with an owner, and the same analysis starts producing actions instead of screenshots.

How do I get user properties into Amplitude?

Through identify calls, sent from your own systems on a schedule. Properties set once at sign-up go stale, and cohorts built on stale properties are wrong in ways nobody notices.

Should I snapshot a cohort or refresh it?

Refresh it. Cohorts are behavioural and membership changes constantly. A snapshot produces outreach to people who already resolved the thing you are contacting them about, which is worse than not contacting them.

Does being in a cohort mean we can email them?

No. Cohort membership is an observation, not consent. Contact preferences still apply, and a large cohort activation is a campaign that deserves the review a campaign gets.

Why does our funnel break between two steps?

Very often identity: one step tracked client-side, the next server-side, without a shared identifier. Check that before concluding the product has a problem at that step.

Should we track clicks or outcomes?

Outcomes. A click tells you a mouse moved; an outcome tells you something happened in the product. Outcome events also survive interface redesigns, which click events do not.

What is the quickest improvement to our data?

Excluding internal and test accounts, usually by a property on the user. Most implementations include them, and for a smaller product they distort exactly the numbers people quote most often.

Should we analyse users or accounts?

Accounts, for anything commercial, with users as the detail underneath. Feature adoption measured per user counts one enthusiast the same as a whole team, and churn happens to accounts rather than to individuals.

Where should group properties come from?

Your billing and CRM systems, pushed on a schedule. Plan, seat count, and renewal date change outside the product, and account-level analysis built on values captured at signup is describing a customer that no longer exists.

How do we spot a broken release in the data?

Watch for cohorts that grow sharply and events that stop arriving, both checked automatically. A step in a funnel collapsing after a deploy is visible within hours if something is looking, and within weeks if nobody is.

Related reading

• Mixpanel and CodeWords
• PostHog and CodeWords
• CodeWords integrations and templates