.NET SDK

using ChurnWarn.Sdk;

// Once at startup (e.g. Program.cs)
ChurnWarn.Initialize(new ChurnWarnOptions
{
  BaseUrl = new Uri("https://your-gateway.example.com"),
  ApiKey = Environment.GetEnvironmentVariable("CHURNWARN_API_KEY"),
  DefaultSource = "my_app",
  BatchSize = 50,
  FlushInterval = TimeSpan.FromSeconds(5),
  OnSendError = ex => Console.Error.WriteLine(ex),
});

// Anywhere — sync, non-blocking
ChurnWarn.CaptureEvent("user-42", RawEvents.AppLogin);
ChurnWarn.CaptureEvent("user-42", Metrics.FeatureUsed, payload: new { feature = "reports" });

ChurnWarn.Shutdown(); // optional: drain + stop on shutdown

Add the ChurnWarn .NET SDK to this .NET 8 / ASP.NET app.

How it works: call ChurnWarn.Initialize(new ChurnWarnOptions { ... }) exactly once at
startup, then ChurnWarn.CaptureEvent(externalAccountId, eventType, payload) from anywhere.
It is fire-and-forget, non-blocking, and batches to POST /api/events/batch.

Please:
1. Add a project reference to ChurnWarn.Sdk and Initialize once in Program.cs. Read config
 from the environment: ApiKey = CHURNWARN_API_KEY, BaseUrl = the gateway URL,
 DefaultSource = "<this-service-name>".
2. Wire OnSendError to ILogger so dropped/failed sends are observable.
3. Register ChurnWarn.Shutdown() on IHostApplicationLifetime.ApplicationStopping so the
 queue drains on graceful shutdown.
4. Use the account id from our own database as externalAccountId (the tenant/organization
 id, NOT the per-user id), and keep payloads to a few small fields.
5. Use the Metrics.* and RawEvents.* constants instead of raw strings.

Leave RedactPayload = true. Do not await CaptureEvent or wrap it in try/catch — it never throws.

Instrument the business signals that feed ChurnWarn's default Product Health dashboard by
adding ChurnWarn.CaptureEvent(externalAccountId, <metric>, payload: <object>) calls in this
codebase. The browser SDK already auto-captures usage, sessions, clicks, frustration and JS
errors — do NOT re-send those from the server. Add only the signals below, each at the call
site described:

- Metrics.Login — in the authentication success path, right after the session/token is issued
(the same place you already record a successful sign-in). payload: { external_user_id = the
signed-in user's id }.
- "active_user" — once per user per day. Add it to auth middleware and guard it with a cheap
per-user-per-day check (cache/Redis/DB flag) so it fires at most once a day per user.
payload: { external_user_id }. Drives the distinct-active-users count.
- Metrics.OnboardingCompleted — where the onboarding/setup flow marks itself done (the final
step handler, or where you flip an "onboarded" flag). Fire once per account.
- Metrics.FeatureUsed — in the handler of a high-value action (report generated, export run,
integration connected), not on every request. payload: { feature = "<stable-short-name>" }.
- Metrics.Session — where a session ends / on logout, if you track session length. Skip it
entirely if you have no session concept. payload: { session_minutes = <number> }.
- "seat_used" and "seat_purchased" — in your billing/subscription code where seat counts can
change (a subscription-updated webhook, a member invited/removed, a plan change). Emit BOTH
with the current counts. payload: { count = <int> } on each (utilization = used ÷ purchased).
- Metrics.SeatExpanded / Metrics.PlanUpgraded — in that same billing path, when seats increase
or the plan moves to a higher tier.
- Metrics.Referral — where a referral is recorded as successful (accepted/converted) in your
invite/referral flow.
- Metrics.NpsResponse / Metrics.CsatResponse — in your survey-submission handler or survey
webhook. payload: { score = <0-10 for NPS / 1-5 for CSAT> }.
- Metrics.SupportTicketOpened / Resolved / Negative — in your ticket lifecycle / support
webhook, ONLY if you do NOT use a Zendesk/Intercom/Freshdesk integration (those map
automatically). payload on Resolved: { resolution_hours = <number> }.

Always pass our own DB account id (the tenant/organization id) as externalAccountId.

Make these changes non-breaking — they must be pure additive telemetry:
- Add each call AFTER the existing operation has fully succeeded (after the DB commit / after
the response is decided). Never change control flow, return values, method signatures, or
business logic.
- CaptureEvent is fire-and-forget and never throws — do NOT await it, do NOT wrap surrounding
code in new try/catch, and do NOT let it block the request path.
- Don't add new blocking I/O; the SDK buffers and sends in the background. Reuse the existing
ChurnWarn.Initialize() — do not re-initialize.
- If you can't confidently find the correct call site for a signal, SKIP it and leave a
// TODO: ChurnWarn <metric> here comment instead of guessing. Omitting a signal is fine;
firing it from the wrong place is not.
- Keep each edit small and reviewable, and keep payloads to the documented fields only.