Skip to main content
What to send a project that is asked to take part in the live proof of adoption (overview.md). Send sections 1 to 6 as they are, with the production domain filled in for <input I4>, and offer the pull request of section 7 for the project’s own repository. Do not send this before production is signed off as ready (../deploy/production-readiness.md): a project must never be asked to install a tag that points at a service that does not run yet.

1. What the service is

Free web and API analytics for Stellar ecosystem projects, run as a shared service for the Stellar Community Fund. Each project sees only its own data; SCF operators see aggregate numbers of every project to compare them for funding and ecosystem visibility. There are no fees for anyone (../compliance/terms.md section 2). The code, including the infrastructure, is open source.
  • Web analytics: page views, unique visitors, referrers, visit duration, bounce rate, countries, and devices and browsers, from one script tag. Built on Umami, with a gateway in front that checks every event.
  • API analytics: request volume, status codes and latency percentiles (p50, p95) per route, from a second OpenTelemetry exporter next to the one your backend already has.

2. What we ask of you

  1. Sign in at https://app.<input I4>/ with GitHub and enroll your project.
  2. Add your site and put one script tag on every page (section 4), or merge the pull request we offer (section 7).
  3. Optionally, for a backend: add the second exporter (section 5).
  4. Keep it installed for at least 14 days. We count only real visitors to your site.
  5. Tell us in writing which of these we may show (each one separately, any of them can be withdrawn later): your project’s name, its numbers in the evidence file, its row in screenshots of the operator views, and a short screen recording of your own dashboard. The recording is made by a member of your team on your account, and shows only your project.

3. Privacy posture

The short version for your privacy review; the full documents are in docs/compliance/ and are drafts until the legal review (plan input I10) is complete.
  • No cookies and nothing stored in the visitor’s browser. The tracker reads one key, an opt-out flag, and honours Global Privacy Control: a browser that sends it is not counted.
  • IP addresses are never stored. The gateway uses the address in memory only, shortens it before the country lookup, and discards it. Region and city are never recorded.
  • Visitors are counted with a token derived from a secret that is destroyed every day at 00:00 UTC, so stored visits cannot be linked to a person afterwards. Unique visitors are therefore unique per UTC day.
  • URLs are cleaned before storage: query parameters are dropped (the utm_ set and ref are kept only for a site that turns on campaign parameters, off by default), referrers are cut to scheme and host, and Stellar keys, secret seeds and email addresses are replaced.
  • For APIs, only request durations with method, route, status code and error type are kept; traces, spans and logs are discarded on arrival (../onboarding/api/what-gets-dropped.md).
  • You are the controller of your visitors’ data and the service is the processor (../compliance/terms.md section 1). Whether you may run the tracker without asking visitors first depends on where they are: ../compliance/jurisdictions.md. Data residency: ../compliance/data-residency.md. You can erase data yourself from the console’s Privacy page (../compliance/erasure.md).

4. Web integration

Follow the web quickstart: enroll, add the site with its allowed origins, copy the tag from Snippet, paste it into the <head> of every page, and check the three requests in the browser’s network tab. Then the guide for your framework: If your site sends a content security policy, add the gateway to script-src and connect-src (content-security-policy.md). If it already uses the Stellar Wallets Kit, wallet connect events can be counted with a small opt-in (wallets-kit.md).

5. API integration

Follow the API quickstart: create a token on the project’s API analytics setup page, add the second exporter with the guide for your language (Node.js, Go, Python, Rust, or your own Collector), and make sure requests carry http.route (http-route.md). Your own observability backend keeps receiving everything as before.

6. What you get

  • A private web dashboard per site with all seven metrics over any range, and a separate view of traffic the platform considered suspicious, kept apart rather than deleted.
  • An API dashboard with requests, status codes, p50 and p95 per service and route.
  • Tokens you create and revoke yourself, members you manage yourself, and erasure you trigger yourself.
  • Support through the public issue tracker, with a first response within 5 and resolution within 10 business days (../support.md).
  • No fees, no lock-in: the tag is pinned to one tracker version that never changes under you, and removing the tag ends collection.

7. Pull request templates

We open these against the project’s repository only after the project agreed, and only with the tag the console shows for that project’s site; the site id, version and integrity hash in the tag come from the console, never from this page. With the example values of the onboarding guides, the tag looks like this:
Before opening either pull request: check the site’s allowed origins in the console include every origin the site is served from (preview deployments too, or set data-domains so previews send nothing), and look for a Content-Security-Policy header or meta tag.

Static site

Title: add privacy-first page analytics (stellar community fund pilot)

React single-page app (Vite)

Title: add privacy-first page analytics (stellar community fund pilot)
The text in angle brackets is filled in for each project before the pull request is opened; a pull request is never opened with any of it left in.