Heap is a product analytics platform with a fundamentally different approach: instead of manually tagging events (track("button_clicked")), Heap automatically captures all user interactions — every click, scroll, input, navigation. Analysts define events retroactively, already having the data. Unlike Amplitude or PostHog, no upfront tagging planning is required. The Kommo integration adds a CRM layer: Won -> identify in Heap -> retroactive analysis of paying customer behavior before the purchase.
Why auto-capture changes analytics
The classic problem: the product team discovers that feature X correlates with retention. They want to understand how users found feature X. But click data on button X was not collected — the developer did not add track(). You need to wait another 30+ days.
Heap: button X was clicked all along — the data exists. The analyst creates an “event” retroactively in the UI, and it instantly becomes available across the full history. Retroactive analysis is Heap’s key advantage.
With the Kommo integration, you gain: “show me the behavior of Growth plan clients in the first 14 days BEFORE and AFTER Won.” Heap can do this retroactively — if identify with plan=Growth was sent.
What gets synchronized
Kommo -> Heap:
— Won -> identify user with CRM properties: plan, mrr, source, deal_id
— Plan change -> update user properties in Heap
— Lost -> add property churned: true
Heap -> Kommo:
— Via Heap Connect (Data Science) — export user segments to CRM (enterprise)
— Via Heap API: get list of users from a segment -> task for manager (at-risk users)
Heap API: key requests
Server-side Track API (for events from backend):
Base URL: https://heapanalytics.com/api.
Authentication: app_id in the request body (public, same as client-side).
import requests
from datetime import datetime, timezone
HEAP_APP_ID = "your_app_id" # from Heap Account Settings
HEAP_BASE_URL = "https://heapanalytics.com/api"
def heap_identify(identity: str, properties: dict) -> None:
# identity: unique identifier - email or userId
# Links server-side events with browser-side sessions
resp = requests.post(
f"{HEAP_BASE_URL}/identify",
json={
"app_id": HEAP_APP_ID,
"identity": identity,
"properties": properties,
},
timeout=10,
)
resp.raise_for_status()
def heap_track(identity: str, event: str, properties: dict = None) -> None:
# Server-side track event
payload = {
"app_id": HEAP_APP_ID,
"identity": identity,
"event": event,
"properties": properties or {},
"timestamp": datetime.now(timezone.utc).isoformat(),
}
resp = requests.post(
f"{HEAP_BASE_URL}/track",
json=payload,
timeout=10,
)
resp.raise_for_status()
def heap_add_user_properties(identity: str, properties: dict) -> None:
# Update existing user properties
heap_identify(identity, properties) # identify is idempotent - updates on repeated call
def on_deal_won(lead: dict, contact: dict):
email = get_contact_email(contact)
plan = get_custom_field(lead, PLAN_FIELD_ID) or "starter"
source = get_custom_field(lead, SOURCE_FIELD_ID) or "direct"
amount = lead.get("price", 0)
# Identify - set CRM user properties
heap_identify(
identity=email,
properties={
"plan": plan,
"mrr": amount,
"customer": True,
"won_date": datetime.now(timezone.utc).strftime("%Y-%m-%d"),
"crm_source": source,
"kommo_deal_id": lead["id"],
}
)
# Track server-side conversion event
heap_track(
identity=email,
event="crm_deal_won",
properties={
"plan": plan,
"amount": amount,
"deal_id": lead["id"],
"pipeline_id": lead.get("pipeline_id"),
}
)
create_kommo_note(lead["id"],
f"Heap: user identified (plan={plan}, mrr={amount})")
def on_plan_upgrade(lead: dict, contact: dict, old_plan: str, new_plan: str):
email = get_contact_email(contact)
heap_add_user_properties(email, {"plan": new_plan})
heap_track(email, "crm_plan_upgraded", {
"from_plan": old_plan,
"to_plan": new_plan,
})
def on_deal_lost(lead: dict, contact: dict):
email = get_contact_email(contact)
heap_add_user_properties(email, {
"customer": False,
"churned": True,
"churn_date": datetime.now(timezone.utc).strftime("%Y-%m-%d"),
})
heap_track(email, "crm_churned", {"deal_id": lead["id"]})
Retroactive analysis: the core value of Heap + Kommo
After integration, the product team can:
1. What paying customers did before Won:
— Heap knows all user actions from the first visit
— After identify with plan=Growth — retroactively segment: “Growth clients in the 30 days before purchase”
— Identify: which features they tried, where they got stuck, what correlates with conversion
2. Activation patterns by plan:
— crm_deal_won (server-side) -> retention cohort in Heap
— Compare: Growth clients vs Starter clients — different product usage patterns
— Find the “aha moment” for each plan
3. Churn prediction:
— Users with churned=True -> what happened in the 14–30 days before churn
— Retroactively — without needing to think in advance about what to track
Heap vs Mixpanel vs PostHog: what makes auto-capture different
| Parameter | Heap | Mixpanel | PostHog |
|---|---|---|---|
| Auto-capture | All events automatically | No — manual tagging | Optional (autocapture) |
| Retroactive analysis | Yes | No | No |
| Session replay | No (separate product) | No | Yes, built-in |
| Open-source | No | No | Yes |
| Self-hosted | No | No | Yes |
Heap wins when: you do not know in advance what matters to track; you need historical analysis without re-tagging; you get many unexpected data questions.
Real-world case
B2B SaaS (US, Kommo + Heap, 30–50 new clients per month):
- Before: the product team wanted to understand why Growth clients retained better than Starter. No behavioral data before the purchase (manual tagging did not cover the needed events).
- After identify with plan from Kommo: retroactive analysis over 6 months. It turned out: Growth clients in the first 7 days activated the API integration — Starter clients did not. Correlation with 12-month retention: 91% vs 34%.
- Action: added API setup to the onboarding flow for Starter -> 12-month Starter retention grew by 23%.
Who this is relevant for
- Product teams with “unexpected” analytics questions — retroactive analysis
- SaaS with multiple plans — need segmentation of paying customers vs trial
- Companies where product and sales use different tools with no connection
- Companies without a data engineer — auto-capture requires no developer tagging
Frequently asked questions
Heap auto-capture — does it create data noise?
It does, if not structured. Heap offers “Event Visualizer”: click on an element in the browser -> create a named event from auto-captured data. All raw clicks are stored; the analyst works only with named events. Noise stays at the raw data level and does not interfere with analysis.
Heap identify — when to do it client-side, when server-side?
Client-side (heap.identify(userId)) — on user login in the browser. This links the anonymous session with a userId. Server-side identify (POST /api/identify) — for updating properties from CRM events (Won, plan, mrr), where there is no browser context. Both methods are compatible — Heap merges sessions.
Heap Data Science / Connect — what is it?
Enterprise feature: Heap Connect exports data to Snowflake/Redshift/BigQuery. Heap Data Science — predictive segments (at-risk users, likely to convert). For Kommo integration this means: at-risk segment from Heap -> task for manager in Kommo (via API). Available on Growth+ plans.
Heap app_id — is it public or private?
app_id is public — used in client-side JS code and in the server-side API. It is not a secret. For data protection, server-side API validation is used (does not accept data from unknown domains).
Summary
- Heap Server-side API:
POST /api/identify+POST /api/track,app_idin the body - identify: set CRM properties (plan, mrr, won_date) on Won
- track:
crm_deal_won,crm_churned,crm_plan_upgraded— server-side conversion events - Key advantage: retroactive behavior analysis before Won — no upfront tagging needed
- Property update: repeat
identifycall with new values
If you use Heap and Kommo and want to add CRM context to product analytics — describe which client properties are important for segmentation. Exceltic.dev will configure server-side identify and conversion event tracking.