Capability guides, not vendor marketing
Amplitude capabilities, explained properly
What a specific Amplitude capability is, when a product or growth team actually needs it, how to implement it without the common mistakes, and how to confirm it worked - integrations, warehouse-native features, setup, and AI agents.
Guide - cohort activation
Sync Amplitude cohorts to Braze
Amplitude's Braze cohort sync sends the membership list of any behavioral cohort you build in Amplitude to Braze as a synced segment, so a lifecycle team can message people based on real product behavior instead of a static import. The sync runs on an interval you configure, so a cohort defined once ("activated but hasn't hit core action in 14 days") keeps updating in Braze without anyone re-exporting a CSV.
Read the guide →Guide - cohort activation
Sync Amplitude cohorts to AppsFlyer
Amplitude's AppsFlyer cohort sync pushes a behavioral cohort's device or user membership into AppsFlyer as an audience, most commonly used to build a retargeting list ("installed but never completed onboarding") or a suppression list ("already converted, stop showing ads") for mobile UA campaigns. The value is that the audience definition lives in the same tool as the product event data that defines it, instead of being hand-maintained as a separate mobile-measurement-partner segment.
Read the guide →Guide - integration
Connect Amplitude to HubSpot: cohort sync and event import
Amplitude and HubSpot connect in two directions: a cohort sync pushes behavioral audiences from Amplitude into HubSpot as lists a sales or marketing workflow can act on, and a separate HubSpot source/event-streaming path brings HubSpot activity (or product events) the other way for unified reporting. Most teams only need the cohort-sync direction; pull in the source integration only if HubSpot itself is a system you need product-usage data to reach.
Read the guide →Guide - integration
Connect Amplitude to Microsoft (Bing) Ads
Amplitude's Microsoft (Bing) Ads integration covers three separate jobs: syncing a behavioral cohort into Microsoft Advertising as a targeting or remarketing audience, streaming conversion events to Microsoft for campaign optimization, and pulling Microsoft Ads spend and click data into Amplitude as a source for blended marketing analysis. Most teams need only one or two of the three, and each is configured independently.
Read the guide →Guide - integration
Stream Amplitude events to Google Analytics 4
Amplitude's GA4 destination streams the same events you're already capturing in Amplitude out to Google Analytics 4 on web, iOS, and Android, so teams that need a GA4 record - for Google Ads integration, a stakeholder who lives in GA4, or a compliance requirement - don't have to instrument and maintain two separate tracking implementations in application code. It is an event-forwarding integration, not a two-way sync: GA4 does not send anything back to Amplitude through this destination.
Read the guide →Guide - integration
Import RudderStack data into Amplitude
Amplitude connects to RudderStack as a destination inside RudderStack's own event pipeline, so a team already routing events through RudderStack to a warehouse or other tools can add Amplitude as one more downstream destination without touching application-level instrumentation. The event names and properties that reach Amplitude are exactly what RudderStack's existing tracking plan defines, which makes RudderStack's own schema discipline - or lack of it - Amplitude's discipline too.
Read the guide →Guide - setup
Amplitude onboarding and initial setup, done right
A new Amplitude instance goes wrong most often not from a bad SDK integration but from skipped sequencing - instrumenting before the tracking plan exists, mixing staging and production events in one project, or deciding on identity strategy after code is already shipped. Getting onboarding right means fixing that order: plan, then structure, then instrument, then govern - never the reverse.
Read the guide →Guide - warehouse-native
Warehouse-native Amplitude: how it works
Warehouse-native Amplitude means Amplitude's analysis layer (cohorts, funnels, retention, dashboards) queries event data that stays in your own data warehouse - Snowflake, BigQuery, Databricks - instead of requiring that data to be duplicated into Amplitude's own event store first. It's a fit for teams whose event data already lives in a governed warehouse and want Amplitude's analytical UI on top of it without a second, parallel copy of the truth.
Read the guide →Guide - warehouse-native
Amplitude warehouse metrics and the Data Warehouse MCP server
Amplitude lets you define metrics directly on top of warehouse tables - a single governed calculation (like activation rate or net revenue retention) that multiple charts and dashboards reuse instead of each one recalculating its own version - and separately exposes a Data Warehouse MCP server so AI agents (including Amplitude's own and general-purpose ones connected via the Model Context Protocol) can query that same warehouse data through a controlled interface rather than raw database access.
Read the guide →Guide - AI enablement
Amplitude AI agents: what they do and when to use them
Amplitude's AI agents are a set of purpose-built assistants layered on top of your event data - a dashboard agent that can build and explain charts from a plain-language request, a website conversion agent focused on funnel and conversion questions, a session replay agent that can summarize what replay sessions show, and a custom-agent framework for building your own - all governed by the same access and privacy controls as the rest of your Amplitude instance.
Read the guide →Guide - core analysis
Building behavioral cohorts in Amplitude
A behavioral cohort in Amplitude groups users or devices by what they actually did - a specific action, within a time window, with optional frequency and property filters - rather than by a static attribute, which is what makes it usable for both analysis and downstream activation into tools like Braze, HubSpot, or an ad platform. Getting a cohort's definition genuinely precise up front matters more than any setting inside the destination it eventually syncs to.
Read the guide →Guide - core analysis
Event segmentation in Amplitude: a practical walkthrough
Event segmentation in Amplitude counts or measures a specific event over time, broken down by whatever property or user segment matters for the question at hand - it's the most-used chart type because most product questions reduce to some version of "how often is this happening, and does it vary by X." The chart is easy to build; the discipline is in choosing the right measurement and the right breakdown before building it.
Read the guide →Guide - agent measurement
Measuring AI-agent usage inside your product without polluting DAU and retention
When an AI agent - an MCP client, a general-purpose assistant, or an operator-style browser - acts inside your product on a user's behalf, it fires real product events that Amplitude counts exactly like human activity unless you deliberately mark them otherwise. Left unmarked, agent-driven usage can inflate DAU, satisfy an activation funnel with a single automated call, and make a retention curve reflect a polling schedule instead of real engagement. The fix is capturing an actor-type property at the moment the event fires, server-side, then using it as a standing segment on every core metric - not a filter applied after the fact.
Read the guide →Guide - agent analytics
Amplitude Agent Analytics: what it measures and how to instrument it
Amplitude Agent Analytics turns an AI agent's sessions, turns, and tool calls into ordinary Amplitude events on the same user_id as the rest of your product data, then scores every closed session on task completion, response quality, user friction, and safety automatically. Because those events land in the same project as your funnels, cohorts, and retention charts, you can ask whether conversion actually drops when the agent fails - not just whether the agent ran.
Read the guide →Guide - consumption KPIs
AI consumption KPIs: cost per conversation, tokens per resolved intent, and margin per seat
When an AI feature is priced by usage - tokens, API calls, compute - the KPIs that matter shift from "how many people used it" to "what did it cost to deliver, and does the value it created cover that cost." Cost per conversation, tokens per resolved intent, and margin per seat are the three consumption KPIs that connect AI spend to the same funnels and cohorts a product team already tracks, instead of leaving it in a finance spreadsheet nobody in product ever opens.
Read the guide →Want this implemented, not just explained?
The free scored audit reads your Amplitude instance across ten dimensions and tells you which of these capabilities are worth building first for your actual setup - no commitment, 48-hour turnaround.
Request the free audit