tinkoff.ru Acquisition from banner click to personalized page
How business goals turned into architecture, processes, and teams around the public web
How business goals turned into architecture, processes, and teams around the public web
How business goals turned into architecture, processes, and teams around the public web
Goals and engineering principles
Process and performance marketing
Frontend and teams
SEO, personalization, tests
Three goals, one system
Many and cheap — Channels scale, not isolated wins
Good UI/UX — Banner-to-application path is fast and relevant
Scalable processes — Campaigns and tests without release bottlenecks
Abstraction, simplicity, feedback, and communication structure
Process model ≠ channel details
Entities: campaign, form, report
The level where business meets IT
No universality until needed
Compact core, specifics outside
A simple model serves the goal
Plan/Do: goal, campaigns, tests
Check: KPIs and deviations
Act: bids, content, resources
Chaotic teams → sprawling system
Topology holds ownership boundaries
The acquisition loop and the team around it
Campaigns, content, client, tracking, and action — one system
One loop for business and IT
Business sets the unit economics
IT covers many technology zones
Core gives tools, products deliver features
Works only with explicit boundaries
Automating paid search, data, and decisions
Campaigns: search, display, targeting
Scaling winners, killing losers
Analysis by channel, keyword, product
Semantics, bids, fast hypotheses
Campaigns, platforms, marts, and reporting in one process
Data, marts, clustering, bids, and reporting
Product owner: goal and priorities
Lead: technical coherence
Developers and analysts: data and reports
Python + Postgres + Rabbit
PHP + React + Material UI
Metabase for reporting
The main communication channel with potential clients
Every business unit is a stakeholder
Unauthenticated zone: first touch, forms
Public web ≠ internet bank
Every unit changes content fast
Frontend is a delivery platform
Thin frontend per product, thick backend of reusable engines
Frontend
Split by products
Shared blocks, forms, tracking
Change velocity
Backend
Separate services and engines
Content, rules, forms, events
Less duplication
Core owns engines; product teams own business functionality
What stays in core and what goes to product teams
Core
Page and block engine
Form engine
Tracking, infra, contracts
Product teams
Business-line functionality
Pages, scenarios, blocks
Hypotheses, A/B, product P&L
Where engineering principles meet delayed feedback
Tasks
Optimize product pages
Unify pages and landings
Behavioral factors via personalization
Problems
Lag between action and result
Algorithms not transparent
Deadline beats the perfect model
Conversion through hypotheses, targeting, and real-time feedback
Hypotheses without a heavy release
Relevant content by targeting
Device, channel, and behavior targeting
Fast statistics back into decisions
A/B tests become system architecture
Load
On every user's path
Decisions must be fast and reliable
Failures show in conversion
Data
Many sources of segments
Real-time stats per variant
Logs → business signals
Owners appear for domains, data, and infrastructure
Senior product owner: goal and priorities
Product owner: the system's backlog
Lead and infrastructure: platform reliability
Customers: experimentation loop
Exceptions usually trace back to the project triangle
Time critical → targeted bypass
Budget limited → local solution
Volume grows → stricter prioritization
Name the compromise's reason and lifetime
Goal first — then process and architecture
Core where needs repeat across products
PDCA rests on tracking and analytics
Conway's Law shapes system and teams
efficient acquisition = process + architecture + team
Talk recording — HighLoad++ 2018
HighLoad++ 2018 abstract: highload.ru
Evolution of tinkoff.ru over 3 Years
polomodov.tech
All slides and links are in the Telegram channel
Alexander Polomodov, Development Manager, Tinkoff
@book_cube