Skip to content
back to the presentation
Talk summary2018

Attracting tinkoff.ru

Alexander Polomodov's HighLoad++ 2018 talk on how customer acquisition works in a bank with no branches: a closed loop from a product plan to end-to-end analytics, four basic engineering principles, two examples where they worked, two where they had to be sacrificed, and what that costs.

HighLoad++ 20189 min read

This summary is shorter than the full talk; examples and assessments reflect the author’s experience and views.

The main thread of the material
01

The acquisition loop and four principles

Alexander opens with the goal: acquire many new customers cheaply, give them a convenient modern interface, and make acquisition processes automatable. His department is a shared one inside the company and owns acquisition for every business line: insurance, investments, mortgages and card products. Every product has an owner carrying a plan - say ten thousand new motor insurance customers next month. The owner splits the budget across channels, channel specialists launch campaigns, and a prospective customer arrives at public content, the site or the mobile app. There are no branches, so he must be served online: product pages and advertising landings assembled, A/B, split and multivariate tests run, whatever works only for part of the audience personalised, and behaviour tracked - which step of the form the person abandoned, which product characteristics he never saw. At the end, online data is merged with offline data in end-to-end analytics dashboards, and the product owner switches channels off or gives them more budget.

Alexander and his teams work from four principles, with abstraction carrying an icon that follows it through the slides. Abstraction is the spherical horse in a vacuum from the physicists' joke: it drops details that do not matter and keeps the characteristics the task needs. The same pickup truck is described to fellow enthusiasts through its engine and top speed, and drawn by the owner's son for his friends at kindergarten. Occam's razor, coined by an English monk for theological arguments, forbids multiplying entities: to travel fast over snow you can bolt tracks onto a bicycle, or simply take skis. The management cycle breaks any activity into planning, action, feedback and a corrective step; one iteration rarely settles the task, and in the middle of the last century this cycle produced the Japanese economic miracle. Conway's law reminds everyone that an organisation reproduces its own communication structure in its architecture. The bank is matrixed and flat, so Alexander assembles teams to fit the target architecture rather than the other way round.

02

Context advertising and a thin frontend

The first example where the principles held is performance marketing, shown through context advertising. A product owner comes to a context specialist: I need five thousand new users, here is the budget. The specialist takes the semantic core and sets up campaigns in Yandex.Direct and Google AdWords; to learn what worked, the team writes its own integrations with the Yandex and Google APIs and pulls statistics on campaigns, their parameters and the budget spent. The data lands in a database, an analyst builds dashboards, the specialist reads the reports - and the cycle closes. Abstraction suggested splitting the system in two: collecting data from external sources, Wordstat among them, and managing campaigns - clustering the semantic core, helping to compose ads, and running bids in-house instead of through an external engine. Two teams grew out of that, with no shared solution, since nobody had asked for one, deliberately on different stacks: integrations on Python with a task queue, admin panels on React and Material UI, reporting left in Metabase until its limits are reached.

The second example is the public tinkoff.ru frontend, the main channel for talking to people who are not yet customers; every business unit in the bank orders changes there. The site splits into the personal account and the unauthenticated part, and the second one drives acquisition, so they kept it thin: minimal logic, a split by product, maximum reuse of shared tooling. The logic moves into the backend, once a monolith and later broken up into services in containers. The frontend came down to three things: a page engine that renders the configuration arriving from the backend, a tracking library that sees clicks and the speed of filling fields, and a form engine fed a description of structure, fields and a DSL for interactions. Reaching that shape took around two years: product teams with their own owners, plus a core team with an architect responsible for the three engines. Answering a question from the floor, Alexander added that core began as research but shipped a form prototype an order of magnitude faster than the old one, then documentation, internal libraries and a release process running the tests of dependent teams.

03

SEO, personalisation and technical debt

The two examples where the principles had to give way fail in different ways. In SEO the feedback loop breaks: a week or more passes between a content change and a shift in search results, the engine's behaviour is opaque - a drop may mean the algorithm was read wrong or the technical implementation was weak - and the SEO specialist's requests, such as structured markup or one page replacing both the product page and the advertising landing for the sake of behavioural factors, cut straight through backend and frontend, leaving no room for a separate architecture. Personalisation and testing break other principles: they run across the whole audience with many variants at once, which makes them high-load; underneath sits statistics - confidence intervals, stopping criteria, sticky variants - which a developer finds hard to turn into code; and the runs produce so many logs that they go into Kafka and a lambda architecture with real-time statistics on Scala and Cassandra. Next to the advertising DSP lives an almost identical content personalisation system - a direct breach of Occam's razor - while the people able to write such systems are several times fewer than the systems.

Alexander's conclusion: the principles work, but inside the project triangle of time, money and scope - money is rarely the blocker, deadlines and scope always press, and when you cannot say no you take a loan that becomes technical debt. The debt grows until it can no longer be repaid: a second version arrives, then a third, all carrying backwards compatibility. Debt is better repaid in parallel: the monolithic backend was rewritten over roughly a year and a half, one service sawn off at a time, until this autumn only a single microservice was left inside the monolith. Answering questions from the floor, he said feature work is never stopped for this - the team is expanded instead, and management is shown in plain terms how the cost of change grows: what took an hour starts taking a day, then more, non-linearly. A new solution is checked with a split test and the end-to-end funnel: what counts is not the form but an activated card, and a variant may cut conversion at the second step yet convert better at the end.

Takeaways

What to take away

  1. 01Design acquisition as a closed loop: product plan, channels, product pages and landings, tracking, and end-to-end analytics that hands the decision back to the product owner.
  2. 02Splitting a system into loosely coupled parts sets the team structure: two teams on different stacks move in parallel, and a shared solution appears only when real repetition appears.
  3. 03A short feedback loop is impossible where the result shows up a week later and depends on an opaque algorithm: SEO work must enter product teams' plans early and at high priority.
  4. 04Technical debt is repaid alongside feature work: the new system grows next to the old, while the business is shown the non-linear growth in the cost of change.

Sources