Skip to content

Ask AI

Ask anything about Destesi — setup, products, APIs.

AI answers may be wrong — always verify against the docs.

Lens

Lens is product analytics and error tracking in one place: pageviews, events, trends, retention and funnels on one side, grouped software defects on the other. One script sends both, so the error you are reading and the session it happened in are the same record.

  1. Open lens.destesi.io and create a project. You get a public key (lens_pk_…) and a secret key (lens_sk_…).

  2. Put the snippet the project page shows in your page’s <head>. It carries the public key, which is meant to be public — it is in the snippet, visible to anyone who views source. Only the secret key is confidential.

  3. Reload your app. The project page turns from “waiting” to a first event within a few seconds. Send test event on that page proves the path without needing a visitor.

A Destesi storefront needs none of this: it already reports.

Pageviews, with the path, the referrer host, the country and a device class. Country and device come from the request itself, never from anything the page sends, so they cannot be spoofed by a client. Only a change of PATH counts as a new pageview — a query-string change does not.

From the browser, with the SDK already on the page:

lens.track('checkout_started', { plan: 'pro', seats: 4 })

From a server, with the SECRET key:

Terminal window
curl -X POST https://api.lens.destesi.io/v1/events \
-H "Authorization: Bearer lens_sk_…" \
-H 'Content-Type: application/json' \
-d '{"schema_version":1,"events":[{"event_id":"evt_1","name":"invoice_paid","person_id":"u_123","properties":{"amount":"4900"}}]}'

The two differ in one way that matters: only the server class marks a person as verified, because only your server knows who is signed in. A public key posted to the server route is refused on its shape, before any lookup.

  • Trends — events and unique visitors per day.
  • Retention — of the people first seen on a day, how many came back.
  • Funnels — declare the steps once, then run it over any window.
  • Breakdown — the top values of one dimension: name, path, referrer host, country, device class, source, person, or any property you send.
  • Segment — narrow to one slice and read everything through it.
  • Errors — uncaught exceptions, grouped, with the events around them.

Two narrowings run through the reads: person and any property. Apply them and the events feed, the segment and the breakdown all answer the narrowed question.

A project has an identity mode. Under the rotating mode a visitor’s id is not stable across days, which makes retention arithmetically impossible — so Lens renders retention as unavailable, with the reason, instead of a number that would be wrong.

You can delete one person’s data, and export a project’s. To erase a person from the web, narrow the project to that person and choose Erase this person…; the page reports how many events were erased.

An error group can be resolved — kept, not deleted, so a return shows up as a regression — or filed as an issue in Space. Filing is deliberately something you do from dst or the lens_file_issue MCP tool, never something the assistant does on its own: it needs your own credentials to write into Space, and the chat session does not carry them.

Set a threshold on a project and Lens tells you when it trips, through Connect. No Connect, no alerts — the rest of the product is unaffected.

Everything above is also dst lens in a terminal and lens_* through MCP, over the same routes. Ask the assistant on the project page, run it in a script, or read it on the web.