Art Quest · Horror Cinema · MORPHEUS
One pictureinstead of five logins.
Websites, bots, CRM, bookings, ads and payments for three businesses lived in separate accounts, and each one answered its own question. We built the company one system: an in-house event tracker, an owner dashboard, a collector that reads 20 sources on timers, and a mirror of amoCRM in a shared database. The dashboard’s main figure is money actions, not visits.
Live · tracker, dashboard and collector on the production server; the weekly package has been built by a timer since 12 October 2026
Where the data comes from
- Websites of three brands
- Telegram and VK bots
- amoCRM and bookings
- YooKassa
- Yandex Metrica
- Search Console
- Avito
- VK
Our own system
- TrackerWebsite and bot events60,557events in three weeks
- CollectorReads sources on timers20sources in the weekly package
- DatabaseDeals, bookings, payments together4,356amoCRM deals in the mirror
What the owner gets
- Owner dashboard19 sections: money actions, funnel, Live
- Weekly packageThe server builds it every Monday
- End-to-end pathClick, bot, booking, payment, deal
- 20sources read by the collectorin the weekly package; 30 in the catalogue
- 60,557events recorded by the tracker5,488 sessions from 8 to 29 October; every row in the events table, service traffic included
- 6 min 45 sfull amoCRM export4,063 deals, 36,263 tasks, 0 errors
- 3 of 3weekly packages built by the timerruns on 12, 19 and 26 October
Each account knows its own piece
Metrica counts visits. amoCRM knows deals. YooKassa sees payments, Avito keeps its own chats and Search Console shows search. None of them can say which post brought the customer who booked a session through a bot and paid for it.
The owner needs an answer to a plain question: where did this week’s money come from. For that, data must meet in one place and speak one language. So we built an in-house system in three layers.
Before
- Metrica counts visits, not bookings
- amoCRM knows the deal, not the page the customer came from
- The website, the bot and the payment write to separate logs
After
- One tracker across the websites and bots
- amoCRM deals sit in the same database as the events
- An end-to-end key ties click, bot, booking and payment; deals gain a website session
- The server builds the weekly package itself
- Layer 1
Tracker
Our code on the websites and in the bots writes events to the database. The registry describes 110 events: when each fires, why it matters and whether it shows on the dashboard.
- Layer 2
Collector
A Python programme on three timers reads external sources and stores the records in its own store. The weekly package draws on 20 sources.
- Layer 3
Dashboard
The owner’s web panel with 19 sections. Its headline figure is money actions, not visits.
The dashboard counts money actions, not visits
The main tile on the dashboard is called Money actions. It adds three counters: uploaded payment receipts, Horror Cinema website bookings and bot enquiries sent to CRM with a real phone number.
A repeated event doubles nothing: receipts are counted by unique booking number, website bookings by unique session and bot enquiries by unique token. It counts actions, not roubles.
In the quiz section live and dead sessions are counted separately. In a live session the visitor did something on the page. In a dead one they arrived and left. Traffic full of empty visits no longer looks like a win.
- 19dashboard sectionshome, websites, ads, bots, CRM, payroll, Live
- 110events in the registrywhen each fires, why, and whether it shows on the dashboard
- 60,557events recorded8 to 29 October, service traffic not filtered out
- 5,488unique sessionsover the same three weeks
The collector reads 20 sources on timers
The collector is a separate programme on the server. Three timers start it: a frequent one, a daily one and a weekly one. It reads Metrica, Search Console, Avito, VK, YooKassa, amoCRM and the booking store, brings records to a common shape and puts them in its own store.
By 9 October the store held 18,390 normalised records, 103 collector runs and 1,762 attribution links. A link answers which channel a deal, booking or payment came from.
- 2,182Yandex Metrica recordsper the 29 September status
- 1,801Search Console recordsas of 29 September
- 999Avito chatsas of 29 September
- 181YooKassa paymentsand 18 refunds, as of 29 September
The collector’s main rule: a failure never becomes a zero. If one of the 17 optional sources does not answer, the package is marked PARTIAL with a warning. If one of the three critical sources fails (the full deal list, the booking store, the calendar), the package is not released.
A separate layer tracks changes to the websites. It normalised 21 changes and 63 follow-up checks at 7, 14 and 28 days after each.
A full amoCRM export in 6 minutes 45 seconds
At 14:26 Tashkent time on 8 October a full amoCRM export started. At 14:33 it finished.
In 6 minutes 45 seconds it pulled 4,063 deals, 8,844 contacts, 36,263 tasks and 5,748 deal notes. That took 253 API calls, with 0 errors. It made no write requests: the export only read data.
The deal mirror sits next to the website events. As of 29 October it holds 4,356 deals. The system adds a website session, an entry page, a booking number and a payment to a deal when they are known.
- 4,063dealsin the 8 October export
- 8,844contacts
- 36,263tasks
- 253API calls0 errors
The weekly package builds without people
Every Monday at 03:30 Tashkent time the server builds the weekly package from 20 sources. Each package gets a SHA-256 checksum, and Drive receives a safe ZIP with aggregates only: no conversations, CRM cards or customer data.
The packages of 12, 19 and 26 October were built by the timer. Nobody pressed a button.
- 7 minfirst scheduled run12 October, 03:30 to 03:37
- 98.6 sfull week build12 phases, a rehearsal on a copy of the store
- 3 of 3runs in a row with no manual start12, 19 and 26 October
What the owner gets from the package each week is covered in a separate case on the weekly business report.
Click, bot, booking, payment and deal on one key
On 28 October an end-to-end key went into the links to the bots: it ties the website, the bot, the booking and the payment together. In the first day the system issued 348 keys.
Deals in the mirror gained a link to a website session: from 0 to 38 of 278 (14%). Now 47 deals have an entry page, 57 a booking number and 39 a payment.
One key along the whole customer path
- 1Clickad, post, QR code
- 2Websitesession and entry page
- 3Botkey in the Telegram and VK link
- 4Bookingkey and session are stored
- 5Paymentpayment tied to the booking
- 6Dealin the amoCRM mirror
348 keys issued in the first day
Sessions with no source: before and after the rule recount
The whole customer path from click to deal is covered in a separate case on end-to-end analytics.
What the data showed
- iPhone
The booking form did not submit from iPhones for five days
From 19 to 23 October the booking form on the Horror Cinema site did not submit from iPhones. The weekly report for 19 to 25 October shows 3 self-service booking enquiries against 12 the week before. Fixed on 23 October.
- Direct
“Direct + search” deals turned out to be calls
41 “Direct + search” deals turned out to be calls to the advertising number. The Direct click tag reached the websites in only 2 sessions, while 730 sessions came from organic Yandex search. Such deals do not show up in website visits.
- Widget
A booking lost its session
11 of 11 bookings through the Horror Cinema website widget before 19 October arrived without a session: a filter took a 13-digit timestamp for a phone number. From 19 October a booking carries the widget session, and from 28 October the widget passes the website session, so a booking joins the visit.
How it was built
Five months from the first dashboard to the end-to-end key
The first working dashboard version dates from 29 May 2026. On 13 June CRM and the bots joined it. By the end of September the collector ran beside it, on 12 October it built its first scheduled weekly package on its own on the new server, and the end-to-end key went in on 28 October.
The company asks the questions: where did the money come from, where do enquiries get lost, what changed this week. We turn each question into an event, a table or a screen.
- The companyQuestions for the data and the choice of sources: what to read, what counts as money.
- SemCueThe tracker, dashboard, collector, amoCRM mirror and end-to-end key.
- The serverTimers start collection and the weekly package by themselves.
For technical readers
Under the hood
- Tracker and dashboard
- Node.js (Express) and PostgreSQL. Website and bot events, the amoCRM deal mirror, 19 dashboard sections.
- Collector
- Python with a SQLite store and three timers: frequent, daily and weekly.
- Package rules
- 3 critical and 17 optional sources. A failed optional source is marked PARTIAL and never becomes a zero. Each package has a SHA-256 checksum, and Drive receives a ZIP with aggregates only.
- End-to-end key
- A key in the bot links, tying the booking, payment and deal to the website session.
Where the numbers come from
Where the figures come from
- The summary file of the full amoCRM export of 8 October 2026: counts, timing and number of API calls.
- The collector status document of 13 October 2026: sources, package rules and run times.
- The service log and the catalogue of weekly packages on the server, as of 29 October 2026.
- Counters from the analytics database as of 29 October 2026: counts only, no content.
- An audit of the collector store of 9 October 2026.
- The dashboard source code and the tracker’s event registry.
- The end-to-end path contract with measurements before and after the 28 October 2026 release, and the weekly report for 19 to 25 October.
Next system
Customer journey: from the first click to payment →