Attracting tinkoff.ru

Each product - card, insurance, mortgage or investment - has an attraction plan. The product owner distributes the budget between channels, specialists launch campaigns, and a potential client lands on a public page and fills out a form. To manage the process, you need to collect pages and advertising landing pages without a release, conduct A/B and multivariate tests, personalize content and track where the user left off. Online events are then combined with banking data in end-to-end analytics, and the product changes budgets, rates, content or the process itself.

Four supports are used for design. Abstraction separates repeatable entities—campaign, page, form, event, and report—from the details of a specific channel. Occam's razor does not allow building a universal platform before real repeatability appears. PDCA closes in on planning, launch, metrics review, and corrective action.

In performance marketing, the process is divided into data collection and advertising campaign management. Integrations received statistics from Yandex and Google, analysts built showcases and reports, and a separate loop helped work with semantics, clustering and bids.

The public frontend Tinkoff.ru has become a platform for delivering changes for all business areas. Product applications were kept thin: pages, scripts and content for a specific business were built on common blocks, forms and tracking. Common engines and rules were moved to backend and reusable libraries. The core team was responsible for the page engine, forms, tracking, infrastructure and contracts, the product teams were responsible for the hypotheses, metrics and functionality of their area. Core did not remain a research group: along with the tool, it created documentation, release processes, and a way to safely update dependent products.

SEO has shown the limitation of a short feedback cycle. Weeks pass between a page change and a search position, search engine algorithms are not transparent, and a specialist’s request can cross the frontend and backend at once. Personalization and testing added another layer of complexity: the decision is made in each user's journey, uses many segment sources, requires real-time statistics, and creates a large stream of events.

Hence an important clarification: the principles work, but within the project triangle of time, money and volume. Sometimes a deadline requires a local solution, and combining two similar systems is more expensive than their temporary coexistence. Such a compromise is acceptable if its reason and price are clearly stated. It is better to pay off technical debt in parallel with development: the old system continues to be maintained by one part of the team, the new one is built nearby and gradually takes away functionality. This is how the monolithic backend was disassembled into services for about a year and a half without stopping business development.