The post has been translated automatically. Original language: Russian
"Marketix" LLP is a Kazakhstani grocery company, a member of the Astana Hub. In the first few months, we went from an idea to two working services for companies that sell on marketplaces: Bidder — working with advertising data, and OMS — collecting orders and transferring them to accounting systems.
It's not interesting to talk about the functions, so below are four conclusions that we made along the way. All of them relate to products built on data from other people's systems, and there are many such among the Hub participants.
1. If the data source does not give the story, you will have to create the story yourself.
Marketplace cabinets show the current cross-section: bids now, positions now, and expenses for today. There is no history by the hour, and there is no public API for advertising tools. This means that any analytics does not start with an interface or a model, but with a stable collection: a snapshot of the state once an hour, one row per object and hour, a regular relational database.
The conclusion that should be laid down in advance is that about half of the effort will be spent not on functionality, but on processing failures and changes in the source. The source changes the layout, gives an empty response, silently loses some of the data — and all this must be experienced without losing lines. We underestimated this share by about half in the first time estimate.
2. Data completeness control is more important than it seems at the start
The most expensive mistake in data collection is not a fall, but a silent skip. If one hour has not been collected for one object, the daily amount for that day is already incomparable with other days. A month later, you build a schedule, see a "failure" and look for the reason in the business, and the reason is in the collector.
Therefore, completeness should be checked automatically and incomplete periods should be marked directly in the data, and not in the analyst's head. This is a boring part of the job, which is not visible in the demo and which cannot be added retroactively: the data for the missed month can no longer be restored.
3. The customer does not buy functions, but the fact that the data will end up where he already works.
When we described OMS through features, the conversation was difficult. When they started asking, "What system does your manager work in every day?" The conversation changed. No one needs another panel to enter; they need the order to appear in the CRM or in the accounting system that is already open on the screen.
The practical conclusion for any B2B product based on data is that the list of integrations sells more strongly than the list of functions, and it should be clarified at the first meeting, not in the middle of implementation. The question ""where should it go"" provides more information than the question "what functions do you need".
4. AI does not work on top of raw data — the order of the layers cannot be jumped
The temptation is great: to connect the language model and get "analytics". In practice, a model without historical data and without a prepared showcase of metrics produces a plausible retelling of the current cross—section - and this is worse than the lack of analytics, because it looks convincing.
The working procedure turned out to be as follows: first collection, then storage with history, then a showcase of metrics, and only on top of it is a model that reads the showcase, not the Internet. Each layer can be checked separately, and when the answer turns out to be strange, it's clear at which level to look. For our tasks, the minimum at which conclusions make sense at all is three to four weeks of accumulated history.
About the status of the Astana Hub member
The company received a certificate of participation in the technopark this year. In addition to the tax regime, which is usually called the first one, access to the community turned out to be important: events, a portal, and the ability to quickly find those who have already solved a similar problem. Advice to those who have just taken shape: fill out the company profile and start publishing immediately, rather than "when there is something to show" — the discussion of technical solutions begins with publications.
We will be happy to discuss the above with the members of the Hub who work with e-commerce, retail, or simply build products based on data from external sources.
ТОО «Marketix» — казахстанская продуктовая компания, участник Astana Hub. За первые месяцы мы прошли путь от идеи до двух работающих сервисов для компаний, которые продают на маркетплейсах: Bidder — работа с данными рекламы, и OMS — сбор заказов и их передача в учётные системы.
Рассказывать про функции неинтересно, поэтому ниже — четыре вывода, которые мы сделали по дороге. Все они касаются продуктов, построенных на данных из чужих систем, а таких среди участников Хаба немало.
1. Если источник данных не отдаёт историю — историю придётся создавать самому
Кабинеты маркетплейсов показывают текущий срез: ставки сейчас, позиции сейчас, расход за сегодня. Истории по часам нет, публичного API для рекламных инструментов тоже. Это значит, что любая аналитика начинается не с интерфейса и не с модели, а со стабильного сбора: снимок состояния раз в час, одна строка на объект и час, обычная реляционная база.
Вывод, который стоит заложить заранее: примерно половина усилий уйдёт не на функциональность, а на обработку сбоев и изменений в источнике. Источник меняет вёрстку, отдаёт пустой ответ, молча теряет часть данных — и всё это надо переживать без потери строк. Мы недооценили эту долю в первой оценке сроков примерно вдвое.
2. Контроль полноты данных важнее, чем кажется на старте
Самая дорогая ошибка в сборе данных — не падение, а тихий пропуск. Если по одному объекту не собрался один час, суточная сумма за этот день уже несравнима с другими днями. Через месяц вы строите график, видите «провал» и ищете причину в бизнесе, а причина в сборщике.
Поэтому полноту надо проверять автоматически и помечать неполные периоды прямо в данных, а не в голове аналитика. Это скучная часть работы, которая не видна в демо и которую невозможно добавить задним числом: данные за пропущенный месяц уже не восстановить.
3. Клиент покупает не функции, а то, что данные окажутся там, где он уже работает
Когда мы описывали OMS через возможности, разговор шёл тяжело. Когда начали спрашивать «в какой системе ваш менеджер работает каждый день» — разговор менялся. Никому не нужна ещё одна панель, в которую надо заходить; нужно, чтобы заказ появился в той CRM или в той учётной системе, которая уже открыта на экране.
Практический вывод для любого B2B-продукта на данных: список интеграций продаёт сильнее, чем список функций, и его стоит выяснять на первой встрече, а не в середине внедрения. Вопрос «куда это должно попасть» даёт больше информации, чем вопрос «какие функции вам нужны».
4. ИИ поверх сырых данных не работает — порядок слоёв нельзя перепрыгнуть
Соблазн большой: подключить языковую модель и получить «аналитику». На практике модель без исторических данных и без подготовленной витрины метрик выдаёт правдоподобный пересказ текущего среза — и это хуже, чем отсутствие аналитики, потому что выглядит убедительно.
Работающий порядок оказался такой: сначала сбор, потом хранение с историей, потом витрина метрик, и только поверх неё — модель, которая читает витрину, а не интернет. Каждый слой можно проверить отдельно, и когда ответ получается странным, понятно, на каком уровне искать. На наших задачах минимум, при котором выводы вообще имеют смысл, — три-четыре недели накопленной истории.
Про статус участника Astana Hub
Компания получила свидетельство участника технопарка в этом году. Кроме налогового режима, который обычно и называют первым, важным оказался доступ к сообществу: мероприятия, портал, возможность быстро найти тех, кто уже решал похожую задачу. Совет тем, кто только оформился: заполнить профиль компании и начать публиковаться сразу, а не «когда будет что показать» — обсуждение технических решений начинается именно с публикаций.
Будем рады обсудить перечисленное с участниками Хаба, которые работают с e-commerce, ритейлом или просто строят продукты на данных из внешних источников.
Share
