1,982 words. Estimated reading time: 9 min.

Customer industry segments

Auto TL;DR

At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

Industry segment list
Template for industry playbook
Description (general overview of what the industry is and the businesses it consists of)
What they care about (i.e. what is most important to their business success)
Industry terminology
Common software used
Important business metrics and data
PostHog products they should be using

We have thousands of customers in PostHog, many of which are in similar industries. As CSMs having an understanding of our customers' industries can help us better be an expert on how PostHog works best for their specific use cases. This page serves as a resource for us to be able to collect and share industry specific vocabulary, important metrics, PostHog best practices, etc. that allow us to quickly ramp up on the industry to better engage with those customers.

Industry segment list

These segments can change as our customer data evolves, but the following serve as a starting point:

AI and data
Consumer software
Developer tools
E-commerce
Education
Enterprise software
Finance
Healthcare
Logistics
Marketing

Template for industry playbook

Eventually each industry listed above will be linked to its own playbook with details its specifics. The following is a template that can be used to create the playbook:

### Description (general overview of what the industry is and the businesses it consists of)
### What they care about (i.e. what is most important to their business success)
### Industry terminology
### Common software used
### Important business metrics and data
    #### Metrics
    #### Data (event taxonomy, person profiles, groups)
### PostHog products they should be using
    #### Product
    	##### Best practices
    	##### Common challenges
    	##### Cross product use cases

Industry segment

Industry segment is a customer property that we use internally at PostHog.

<summary>AI and data playbook</summary>

AI and data description

Companies that exist in different parts of the AI value chain. There is significant potential to develop further playbooks for each sub-segment.

Sub-segments

| Sub-segment | Examples | Description | |:------------------------|:-----------------------------------|:---------------------------------------------------| | Hyperscalers | AWS, GCP, Oracle, Azure | AI services in the cloud | | Frontier model labs | OpenAI, Anthropic, Cohere, Mistral | Foundation models with proprietary architectures | | Generative | ElevenLabs, Runware, Runway, Luma | Product suites around output | | Inference | Replicate, fal\.ai, Together\.ai | Host / serve other models, making them easy to run | | AI-native applications | Cursor, Perplexity | End-user tools where experience is driven by AI | | Data / machine learning | Databricks, Hugging Face | Orchestration, system management |

What they care about

They share a developer-centric focus on adoption and retention. The higher-order sub-segments (hyperscalers, frontier model labs, inference) care about competitive parity and platform stickiness. Generative and AI-native application segments care about feature adoption, generation metrics, unit economics, and retention.

Sub-segments differ on what they track as output. Generative customers measure the artifact itself, like whether a change increased how often users download an image after generating it. AI-native application customers measure task completion rates and time saved.

Industry terminology

Observability – Monitoring model performance, token use, latency, unit economics, and hallucination rates in production. Most relevant to teams shipping features that interact directly with users.

Feature store – Centralized system for serving, storing, and managing machine learning features that are used in training and inference. These are more commonly found with mature data organizations.

Tokens – Units of processing/billing for LLMs. Can vary based on segment. Other variations would involve count, prediction, job, credit.

RAG (Retrieval-Augmented Generation) – An architecture pattern where an LLM pulls from external knowledge sources before generating a response. For segmentation, RAG-based products have unique infrastructure needs like accuracy of retrieval and context window usage.

Benchmark – A standardized test set for comparing model capabilities.

Latency – Time between sending a request and receiving a response.

Throughput – Number of requests/tokens processed per unit of time.

NLP (Natural Language Processing) – Branch of AI that enables computers to understand and generate human language.

Embedding – Representation of data (text, image, user actions) as vectors used for recommendation, search, and classification.

Common software used

_Note: This list is incomplete, ongoing, and has overlap. It is meant to serve as a directional guide versus ground truth._

Observability: LiteLLM, Helicone, Datadog, Langfuse, Splunk
RAG: LangChain, Cohere, Haystack, Chroma
Feature stores: Tecton, Databricks, SageMaker, Redis
Data warehouse: Snowflake, Databricks, Firebolt, BigQuery
Unit economics: FinOps tooling, Helicone, LiteLLM, OpenRouter
Data pipeline: Atlan, Alation, dbt, FiveTran, Apache Airflow, Stitch

You should make yourself familiar with how each of these products stacks together in a customer's value chain. It's a "current events" practice that will allow you maximum ability to speak to how customers can turn a disparate system of tools into one AI and data centric Howitzer.

Important business metrics and data

Metrics

| Metric | Measurement | Business context | |---|---|---| | Cost per action | Infrastructure cost to serve a particular user action (cost per image generated, cost per second of video generated, cost per query, API call) | User interaction drives margin | |Feature margin|Revenue against how much it costs to run the feature | Can be complex if infrastructure does not support granular definition of feature |

Data

Event taxonomy

AI and data customers should be running AI Observability. It sets the taxonomy: with the SDK you get structured generation, trace, and cost events out of the box. Without it, taxonomy falls back to whatever the customer wires up by hand. Those structured events are also what PostHog's agentic products read, so clean instrumentation is the prerequisite for any self-driving analysis on top.

Without the AI Observability SDK:

Autocaptured clicks and pageviews on AI features (button presses, route changes)
Custom events the customer wired up by hand, like chat_message_sent or prompt_submitted
Whatever properties a customer should choose to attach

With the AI Observability SDK:

$ai_generation – one row per LLM call with model, input/output tokens, cost, latency, and provider
$ai_trace and $ai_span – parent/child structure for multi-step agents and tool use
$ai_embedding, $ai_metric, $ai_feedback – vector ops, eval scores, thumbs up/down

Person profiles

When companies look at their event data in this segment, they're trying to answer "who did this?" and "who are the power users?". Tie every generation to a person profile, and give that profile a defined user_role (admin, for example) alongside aggregations like total_api_calls or total_tokens_used. Without it, you can see that tokens are being burned but not who is burning them.

PostHog products they should be using

Lead with AI Observability. It's the one product built for how these customers make money: it captures every model call as a structured event with cost, latency, tokens, and provider. That event stream is the foundation everything else builds on, from cost analysis to experimentation to the self-driving loop. Get the customer onto it first, then layer the rest.

AI Observability

Best practices

Instrument model calls server-side with the AI Observability SDK, where the model actually runs, and identify on the same authenticated request so every $ai_generation ties to a person.
Attach model, provider, and feature (or prompt version) as properties on the generation, so cost and latency can be sliced by what the customer ships.
Capture cost on the generation event itself. Don't reconstruct it later from token counts.
Set person properties from the server-side source of truth, not client state. Use $set_once for immutable values (signup date, acquisition channel) and $set for mutable ones (plan tier, role, last active feature).

Common challenges

High event volume meets cost sensitivity. LLM apps are chatty and margin-conscious, so ingestion cost gets scrutinized. Lean on sampling, ingestion filters, and dropping high-cardinality properties they'll never query. Don't re-send person properties ($set) on every high-volume event, since that inflates ingestion for no analytical gain.
The events that matter fire server-side. Client-only instrumentation misses the actual model calls, so identify on each authenticated server request.
Environment density. Staging, eval, and simulation traffic pollute production data. Split by project or enforce a strict environment property.

Cross-product use cases

AI Observability – join $ai_generation cost back to person properties for cost-per-segment, or to identify which plan or role is burning the most tokens.
Feature Flags and Experiments – gate new models behind flags, run A/B tests on prompt changes, hold out high-value users from risky rollouts.
Surveys – trigger feedback prompts after a generation, collect CSAT on AI features, run PMF surveys against power users.
Session Replay – filter to recordings of users hitting prompt failures or specific $ai_generation errors.
Replay Vision – run scanners over those recordings to auto-flag dead ends and prompt failures, then query the results back as PostHog events.
Error Tracking – group exceptions by plan, model, or role to see which segment hits a bug.
Data Warehouse – sync events for joins against billing or model cost tables, then pipe insights back.
Self-driving – point the self-driving loop at these signals: agents investigate the reports, open pull requests for fixes, and measure whether they worked.

<summary>E-commerce playbook</summary>

E-commerce description

Online retail businesses including direct-to-consumer brands, marketplace platforms, and omnichannel retailers selling physical or digital goods through web and mobile.