Track SDK adoption after release

Measure whether developers upgrade to a new customer-facing SDK version after launch and which accounts remain behind.

Updated · published

markdown for agents →

difficulty intermediate · time to value 5 minutes · execution on demand
#analytics #deploys #sdk #releases #devtools #product

Start from this 

After the latest SDK release, show adoption by version, language, account, and API usage. Identify accounts still on old versions.

Why this matters

SDK launches do not create value until customers actually upgrade. Product and developer relations teams need to know whether a release is spreading or sitting unread in a changelog.

What you get

  • Adoption curve by SDK version and language
  • Accounts still using deprecated versions
  • API usage volume by version
  • Upgrade targets for CS or developer relations

Walk through it

You

Did customers adopt the SDK version we released last week?

Agent

I’ll find the latest release, then group SDK initialization and method calls by version.

Endpoint: GET /v1/projects/:project_id/deploys
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fdeploys&method=get
Use query parameters, not a JSON body.
Query/filter concept:
  limit: 5
Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.sdk_version AS version, properties.language AS language, count(DISTINCT properties.account_id) AS accounts, count() AS events FROM events WHERE event IN ('sdk_initialized','sdk_method_called') AND timestamp > now() - INTERVAL 30 DAY GROUP BY version, language ORDER BY accounts DESC"

The output

The agent returns adoption by version and language, then calls out large customers still on old versions. It should recommend docs, outreach, or compatibility fixes depending on the pattern.

Setting it up

Emit SDK usage events from the customer’s application or API edge when requests include SDK metadata. Do not imply Agentry has an SDK; this workflow is about your product’s customer-facing SDKs.

Variations

  • “Show Python SDK adoption after the release.”
  • “Which enterprise accounts are still on deprecated versions?”
  • “Compare error rate by SDK version.”

Related workflows

ops 1 minute

Who's still on the old client?

Distinct users per app_version over 7 days. See the long tail of old clients — informs the force-update decision and deprecation timing.

ops 3 minutes

Per-customer API call analytics

Group api_request events by customer_id over 30 days with daily breakdown. The view usage-based pricing needs but most teams cobble together from logs.

growth 5 minutes

Which doc page leads to the most API adoption?

Funnel from a docs page view to first api_request by the same distinct_id within 7 days. Per-doc-page breakdown — find the highest-leverage page in your docs.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows