#Analytics: Overview

Status: Available — collection through loader.js, CMS modules, and the JS/PHP tracker by token. Available through the API — reading analytics and dashboards (pages 07–08). Planned — the server API for events and offline conversions (pages 05–06).

Purpose: explain which data Walker Formulation Academy collects from a site, which paths it takes into the platform, how to choose a path for your site, and what happens to visitors' personal data along the way.

#What we collect and what you get

Data collection is not an end in itself: Walker Formulation Academy links a visit, an inquiry, and revenue into one chain and answers the question "which channel pays off". Raw events stay inside the platform; the public API returns aggregates.

What	Where it comes from	Where to see it
Traffic sources (search, social, ads, direct visits)	visit hit (referrer, UTM)	Overview screen → Sources
Referrals from AI assistants (ChatGPT, Perplexity, Gemini, Copilot, You, Claude, Alice, DuckAssist, Mistral, DeepSeek)	referrer host	Overview → AI assistants
Visits by AI crawlers and search bots	User-Agent; bots are visible only to the server beacon or the tracker by token	Overview → AI assistants
Lead attribution (source, UTM, visit history)	tracker session + the site's form or chat	lead card in the CRM
Funnel (impressions → clicks → sessions → leads → deals → revenue)	search, counters, CRM	Overview, funnel block
Search visibility	Search Console, Yandex Webmaster, Bing, AI citation measurements	Overview, Visibility section
Strategist reports	everything listed above	AI strategist screen

The JS visit counter (paths 1 and 3) uses no cookies or localStorage and sends one hit per page load. The data collected by behavior tracking and by the chat is described on the Loader page.

#Four collection paths

No.	Path	What it sends	Sees bots	Requires	Status	Page
1	`loader.js`: one `<script>` tag	visit counter, behavior tracking, on-site chat	no (JS does not run)	a bound site (you get the key when a module binds it)	Available	02
2	CMS module with a signed server beacon	the same + a server hit for every view, article publishing	yes	Bitrix, WordPress; FastAPI and Nuxt are Beta	Available (Bitrix, WordPress); Beta (FastAPI, Nuxt)	03
3	JS/PHP tracker by token	one visit: path, source, UTM	the PHP variant does	tracker token (`seo.manage` permission)	Available	04
4	Events API `POST /analytics/events`	pages, events, forms, conversions	depends on your server	API key with the `analytics:write` scope (no charge)	Planned	05

Offline conversions (06) complement the fourth path. To read results through the API (scope analytics:read), see 07; for ready-made slices of the Overview and Pulse screens (scope dashboards:read), see 08.

#How to choose a path

Is your site on Bitrix or WordPress?
├─ yes → use the module (path 2). It installs the loader and the server beacon itself.
└─ no
   ├─ is your site on FastAPI or Nuxt, and do you need bots and chat?
   │     → FastAPI/Nuxt module (path 2), currently Beta: the package is not published
   ├─ do you only need a visit counter on any site?
   │     → JS tag (path 3); for a server side in PHP, use the PHP variant
   ├─ do you need chat and behavior tracking on any HTML site?
   │     → loader (path 1); the key is issued when the site is bound
   └─ do you need events, an SPA, a mobile app, payments from a CRM?
         → Events API (path 4), Planned; until it ships, use path 3 for visits

The paths are not mutually exclusive, but do not put two counters on one page without need: the JS tag (path 3) and the loader (path 1) each send one hit, so visits will be doubled. A module (path 2) already includes the loader's counter, so a separate JS tag next to it is not needed.

Question	How it works
Storage of IP and User-Agent	not stored in clear text. We store `sha256(salt \| value)` truncated to 32 hex characters; the salt lives only on the cloud side. With no salt, the hash is `null` and the value is not recorded
Hit retention	180 days
Cookies and localStorage	the JS counter (paths 1 and 3) does not use them
Server beacon mode	`full`: IP and User-Agent hashes, country; `anonymous`: the hashes, country, and User-Agent sample are nulled; `off`: the beacon is disabled
Default value	RU: `full`; EN and ID: `anonymous`
Visitor consent in the loader	`consent_mode`: `wait` (wait for the consent call) or `immediate` (start at once). Details: Loader
Cannot be revoked	a hit that has already been sent. Revoking consent stops further behavior tracking

In anonymous mode, unique visitors cannot be counted (the estimate is built from IP and User-Agent hashes over a day): only views remain. This is a deliberate choice for the EN and ID markets.

The consent banner and the legal basis for processing are the responsibility of the site owner and of the legal entity of its cell. Walker Formulation Academy provides technical switches; it does not replace a legal assessment.

#How the section pages are organized

Each page begins with a status: Available, Beta, or Planned. Pages with the status "Planned" describe an agreed contract; field names will be finalized in OpenAPI 3.1. Errors, pagination, idempotency, and limits of the server API are shared by all methods; see API conventions. Cell addresses:

Cell	Address
RU	`https://formula-cream.pro`
EN	`https://wfacademy.org`
ID	`https://wfacademy.id`

All keys and tokens in the examples are fictitious.

#Open questions

For the owner. The legal wording of consent for banners on EN and ID is not recorded in the project documents; text from the legal entities of the cells is needed.
For the owner. Where to show the "loader key" publicly without a module binding; see Loader.

The remaining questions of the section are on pages 05, 06, 07, 08.