В текущих реалиях многие магазины стали гораздо более активно уходить в онлайн и прокачивать собственную доставку, чтобы не терять клиентов. У «ВкусВилла» на начало года уже была собственная неплохая доставка, которая приносила больше лидов, чем доставка силами партнеров. Но как бы то ни было, чтобы больше людей могли получать свои заказы (а главное — получать их быстрее) активно развиваются и интеграции со сторонними службами доставки.
За последние несколько месяцев мы в Автомаконе интегрировали «ВкусВилл» с двумя большими российскими партнерами. Для нас это был первый опыт интеграций с такими крупными компаниями. Но что интересно, для партнеров опыт интеграции тоже оказался в новинку. Деталями этого двустороннего процесса я бы и хотел поделиться.
При проведении интеграции мы предпочитаем работать на основе пул-модели: партнеры предоставляют нам API, по которому мы запускаемся в качестве сервера, и по запросу выдаем им нужную информацию. Например, каталоги товаров и торговых точек, остатки на текущий момент. Это тот минимальный набор необходимой информации, которая нужна партнерам, чтобы на своей стороне сформировать заказ и передать его нам.
Некоторые партнеры дополнительно настаивают на каких-то дополнительных нюансах, например, получении веб-куки. Часто мы можем пойти им навстречу: наше преимущество в том, что мы довольно гибкие и имеем большую свободу действий, поэтому внести какие-то изменения на нашей стороне бывает сильно проще, чем на стороне большого партнера. Но во всех таких ситуациях мы в первую очередь учитываем пожелания бизнеса, который и ставит нам задачи по интеграциям.
Дальше программист PHP пишет методы, начиная с авторизации. Как правило, работаем по стандартному сценарию. Чтобы интеграция заработала, нам нужно обмениваться определенными сегментами информации, о которых я уже сказал. Дальше мы синхронизируемся с партнером по статусам. Если мы работаем по API партнера, естественно, что наши внутренние статусы не совпадают со статусами заказа, которые приняты на той стороне. Для таких случаев мы пишем таблицу маппинга статусов и тестируем ее.
Сначала тесты проводятся без участия магазинов. Мы создаем какой-нибудь заказ напрямую в системах партнера и смотрим, в каком виде он у нас, а в каком — у партнера. Дальше уже выбираем какой-нибудь один магазин для тестирования, но и в этой ситуации заказы все еще генерируются искусственно. Затем мы этот магазин переводим на полноценную работу с партнером, и он начинает принимать живые заказы. А в конце мы постепенно масштабируемся на магазины в рамках города и регионов.
Наша задача — провести заказ партнера через ручку — метод, и отдать всю информацию в нашу общую базу данных. Если говорить про стек, то методы мы пишем на PHP, а дальше в ход идет большая база SQL. Эти методы взаимодействуют с корневыми процедурами, написанными на SQL, которые уже создают заказы и прочее.
На данный момент мы провели интеграцию с маркетплейсами, службами доставки еды из ресторанов и, собственно, курьерами — службами такси.
В общем процесс передачи заказа через Delivery Club и другого сервиса доставки готовой еды выглядит вот так. Пользователь открывает приложение партнера, видит, что есть доставка из «ВкусВилла», и радостно начинает оформлять заказ. Когда пользователь сформировал корзину, партнер передает ее нам, магазин ее обрабатывает и возвращает обратно уже измененную корзину. А дальше готовый заказ ждет курьера партнера и отправляется вместе с ним к человеку, который его оформил. Магазины при этом обслуживают все заказы в порядке живой очереди, откуда бы они ни поступали — от партнеров или из приложения и сайта «ВкусВилл».
На первый взгляд, ничего сложного, но. Нельзя не учитывать тот факт, что покупатели заказывают из продуктовых магазинов не только штучные товары, но и весовые. Для нас весовые товары — это довольно большой сектор ассортимента, очень важно, чтобы у нас была возможность его доставлять покупателям. Но в процессе организации работы с компаниями, которые всегда доставляли только готовую еду, но никак не продукты питания, мы столкнулись с некоторыми ограничениями.
Партнер обычно не очень охотно идет на изменение заказа, а в ситуации с весовыми товарами это неизбежно: история знает весьма мало случаев, когда при взвешивании апельсинов удается попасть в яблочко и положить в пакет ровно 600 граммов этих самых апельсинов. Ни больше, ни меньше.
Работая с весовыми товарами, невозможно избежать использования квантов. Квант — это средняя мера веса весового товара. Если мы говорим, например, про ананасы или курицу, в этих случаях квант определяется на основе среднего веса определенного количества товара. Знание о таком кванте приходит с опытом: если вы полгода поторгуете курицей, то узнаете, что ее средний вес — 900 граммов, у ананасов — 1 200 граммов.
У весовых товаров, обычно не покупаемых поштучно, например, яблок, квант рассчитывается из среднего веса одного пакета, который обычно берет покупатель. Так в магазинах «ВкусВилл» один квант яблок равен 600 граммам.
Когда мы договаривались с одной из служб доставок о работе с весовыми товарами, было решено, что они будут принимать от нас цену за квант. И здесь нас ждала другая проблема: цена за один квант никогда не получается круглой — обязательно будут копейки. А партнеры не работают с копейками.
Поэтому мы решили отдавать партнеру квант целым, а он будет умножать его на количество квантов и округлять. Но двойное округление, пройдя по кругу, дает нам расхождение, причем порой даже не просто в копейки, а уже в рубли. Тогда мы предложили принимать наши цены по заказу, потому что на кассе в любом случае должна соблюдаться формула «количество х цена = сумма», вне зависимости от того, куда и кому мы передаем цены за кванты. И это то, над чем наша команда сейчас работает.
С технической точки зрения тонким моментом интеграции было время парсинга каталога. У нас больше тысячи магазинов, каждый из которых имеет свою товарную матрицу. И процесс получения партнером каталога в разрезе всех магазинов занимает много времени. Сейчас мы прорабатываем это направление и внедряем механизмы кеширования данных, чтобы обмениваться уже только изменениями.
Первое время после запуска у нас также были сложности из-за человеческого фактора. Наши сборщики могли вместо клюквенного морса положить брусничный, заказ уходил к партнеру, а он не мог его принять, потому что этого морса не было в первоначальном заказе. С этой проблемой нам помогли справиться ребята, которые у нас занимаются фронтом: они прямо на кассах запретили замену товара для определенных партнеров.
В целом можно сказать, что у нас получилась полноценная интеграция с двумя самыми крупными службами. Да, есть над чем работать, но главная функциональность — прием и доставка заказа — работает довольно успешно.
Одной из главных целей нашей общей работы — максимально эффективная доставка товара, точнее, минимизация времени жизни заказа с момента наполнения корзины в приложении и до момента, когда заказ окажется у двери клиента. Поэтому мы интегрировались не только с партнерами-маркетплейсами, но и со службами доставки — Gett, Яндекс Такси, а также службой Net Fi.
Здесь нам важно определить возможность пешей или автомобильной доставки в зависимости от двух важных критериев: расстояния и веса заказа. Например, есть конкурс служб доставки, которым мы можем отдать заказ. Это может быть как наша внутренняя служба доставки, так и внешняя. И здесь можно настраивать в зависимости от приоритета одной службы перед другими, либо в разрезе магазинов и прочего.
Естественно, не бывает такого, чтобы две совершенно разные системы вошли в пазы друг друга как по маслу. Например, был вопрос с форматом адресов. Кому-то обязательно нужно, чтобы отдельно выделялись подъезд, квартира и этаж, а кому-то достаточно указать все это в комментарии. Опять же, авторизация и личный кабинет у каждой службы работает по-своему.
И как правило, API не всегда описывает все возможные случаи, которые могут произойти в процессе промышленной эксплуатации. Поэтому бэклог у нас полон, но нет таких задач, для которых не находится решение.
Как всегда, за любым процессом стоят люди. Мы в Автомаконе считаем, что для реализации непосредственно технической части интеграции с внешним партнером хватит трех человек: аналитика, специалиста по PHP, который пишет аутентификацию с партнером и все методы, обрабатывает запросы партнера и прочее, и программиста SQL, который полученную информацию раскладывает по нужным таблицам и так же по запросу партнера, транслируемому через через PHP в корневую процедуру, возвращает ему нужную информацию. Собственно, в таком составе мы и работаем.
Иногда возникают ситуации, в которых нам нужна помощь коллег. Тогда мы можем взять «напрокат» специалиста из той области, в которой у нас произошел затык. Такой обмен работает в обе стороны и помогает нам быстрее добиваться результатов.
Мы работаем по Agile: три раза в неделю проводим утренние стендапы по задачам и их статусам, определяя их приоритеты, проводим встречи с заказчиками и ретроспективы у команд. В общем, весь тот классический набор, который подразумевает эта методология, старались не придумывать чего-то своего и не переписывать Agile под себя…
Интеграция с внешними партнерами — это только верхушка айсберга. Есть еще интеграция с контрагентами, поставщиками, нашим сайтом и мобильным приложением. Сейчас мы идем по пути распределения информации между базами, и интеграции внутри компании тоже стали востребованы. Во весь этот процесс у нас вовлечены 13-14 человек, плюс люди из управления электронной коммерции, которые нам ставят задачи. А мы, в свою очередь, выбираем методы их реализации.
При этом сказать, что интеграционный процесс — это работа одной, хоть и большой, команды, нельзя. За работой всей системы в целом стоит множество команд, отвечающих за фронт, архитектуру системы, структуру наших внутренних документов и другие важные вещи.
Не стоит забывать и об админке, где можно посмотреть любой заказ, время его создания, проследить его путь и узнать службу, которая этот заказ будет доставлять. Также через админку мы передаем информацию о такси: номер автомобиля, имя таксиста и прочее.
Интеграция с внешними партнерами — сложный процесс, во многом потому что здесь не все зависит от разработчика. Партнеры — это два больших бизнеса, и чтобы внести какие-то изменения в процесс, нужно приложить много усилий всем сторонам. Да, работа с весовыми товарами все еще далека от идеала и требует доработки. Но интеграции уже проведены, мы их развиваем и заказы приезжают к клиентам. И я очень надеюсь, что большинство из них довольны.
Параллельно мы развиваем совершенно новое для нас направление, которое считаем перспективным.
Здесь перед нами открывается внушительный спектр задач. Проектирование каталогов и размещение данных в ситуации, когда мы одновременно и сами выступаем маркетплейсом, который принимает товары, и отдаем сторонним партнерам информацию о себе. Возникают мощные потоки данных, которыми нужно грамотно управлять.
Глобально для «ВкусВилла» приоритетная задача сейчас — это оптимизация механизмов доставки товаров до конечного покупателя. Наша команда также вовлечена в этот процесс и работает над геомодулем, который определяет самый оптимальный путь и способ доставки корзины покупателя в зависимости от ассортимента.
Это огромный блок задач, куда входит и работа с координатами, и оптимизация маршрутов, учет городского трафика и расчет оптимальной нагрузки на службу доставки. Которые тоже нужно совершенствовать.
О чем из внутренней работы вам было бы ещё интересно почитать?
За последние несколько месяцев мы в Автомаконе интегрировали «ВкусВилл» с двумя большими российскими партнерами. Для нас это был первый опыт интеграций с такими крупными компаниями. Но что интересно, для партнеров опыт интеграции тоже оказался в новинку. Деталями этого двустороннего процесса я бы и хотел поделиться.
Как все работает
При проведении интеграции мы предпочитаем работать на основе пул-модели: партнеры предоставляют нам API, по которому мы запускаемся в качестве сервера, и по запросу выдаем им нужную информацию. Например, каталоги товаров и торговых точек, остатки на текущий момент. Это тот минимальный набор необходимой информации, которая нужна партнерам, чтобы на своей стороне сформировать заказ и передать его нам.
Некоторые партнеры дополнительно настаивают на каких-то дополнительных нюансах, например, получении веб-куки. Часто мы можем пойти им навстречу: наше преимущество в том, что мы довольно гибкие и имеем большую свободу действий, поэтому внести какие-то изменения на нашей стороне бывает сильно проще, чем на стороне большого партнера. Но во всех таких ситуациях мы в первую очередь учитываем пожелания бизнеса, который и ставит нам задачи по интеграциям.
Дальше программист PHP пишет методы, начиная с авторизации. Как правило, работаем по стандартному сценарию. Чтобы интеграция заработала, нам нужно обмениваться определенными сегментами информации, о которых я уже сказал. Дальше мы синхронизируемся с партнером по статусам. Если мы работаем по API партнера, естественно, что наши внутренние статусы не совпадают со статусами заказа, которые приняты на той стороне. Для таких случаев мы пишем таблицу маппинга статусов и тестируем ее.
Сначала тесты проводятся без участия магазинов. Мы создаем какой-нибудь заказ напрямую в системах партнера и смотрим, в каком виде он у нас, а в каком — у партнера. Дальше уже выбираем какой-нибудь один магазин для тестирования, но и в этой ситуации заказы все еще генерируются искусственно. Затем мы этот магазин переводим на полноценную работу с партнером, и он начинает принимать живые заказы. А в конце мы постепенно масштабируемся на магазины в рамках города и регионов.
Наша задача — провести заказ партнера через ручку — метод, и отдать всю информацию в нашу общую базу данных. Если говорить про стек, то методы мы пишем на PHP, а дальше в ход идет большая база SQL. Эти методы взаимодействуют с корневыми процедурами, написанными на SQL, которые уже создают заказы и прочее.
Интеграция с внешними партнерами — подводные камни
На данный момент мы провели интеграцию с маркетплейсами, службами доставки еды из ресторанов и, собственно, курьерами — службами такси.
В общем процесс передачи заказа через Delivery Club и другого сервиса доставки готовой еды выглядит вот так. Пользователь открывает приложение партнера, видит, что есть доставка из «ВкусВилла», и радостно начинает оформлять заказ. Когда пользователь сформировал корзину, партнер передает ее нам, магазин ее обрабатывает и возвращает обратно уже измененную корзину. А дальше готовый заказ ждет курьера партнера и отправляется вместе с ним к человеку, который его оформил. Магазины при этом обслуживают все заказы в порядке живой очереди, откуда бы они ни поступали — от партнеров или из приложения и сайта «ВкусВилл».
На первый взгляд, ничего сложного, но. Нельзя не учитывать тот факт, что покупатели заказывают из продуктовых магазинов не только штучные товары, но и весовые. Для нас весовые товары — это довольно большой сектор ассортимента, очень важно, чтобы у нас была возможность его доставлять покупателям. Но в процессе организации работы с компаниями, которые всегда доставляли только готовую еду, но никак не продукты питания, мы столкнулись с некоторыми ограничениями.
Партнер обычно не очень охотно идет на изменение заказа, а в ситуации с весовыми товарами это неизбежно: история знает весьма мало случаев, когда при взвешивании апельсинов удается попасть в яблочко и положить в пакет ровно 600 граммов этих самых апельсинов. Ни больше, ни меньше.
Копейка рубль округлит
Работая с весовыми товарами, невозможно избежать использования квантов. Квант — это средняя мера веса весового товара. Если мы говорим, например, про ананасы или курицу, в этих случаях квант определяется на основе среднего веса определенного количества товара. Знание о таком кванте приходит с опытом: если вы полгода поторгуете курицей, то узнаете, что ее средний вес — 900 граммов, у ананасов — 1 200 граммов.
У весовых товаров, обычно не покупаемых поштучно, например, яблок, квант рассчитывается из среднего веса одного пакета, который обычно берет покупатель. Так в магазинах «ВкусВилл» один квант яблок равен 600 граммам.
Когда мы договаривались с одной из служб доставок о работе с весовыми товарами, было решено, что они будут принимать от нас цену за квант. И здесь нас ждала другая проблема: цена за один квант никогда не получается круглой — обязательно будут копейки. А партнеры не работают с копейками.
Поэтому мы решили отдавать партнеру квант целым, а он будет умножать его на количество квантов и округлять. Но двойное округление, пройдя по кругу, дает нам расхождение, причем порой даже не просто в копейки, а уже в рубли. Тогда мы предложили принимать наши цены по заказу, потому что на кассе в любом случае должна соблюдаться формула «количество х цена = сумма», вне зависимости от того, куда и кому мы передаем цены за кванты. И это то, над чем наша команда сейчас работает.
С технической точки зрения тонким моментом интеграции было время парсинга каталога. У нас больше тысячи магазинов, каждый из которых имеет свою товарную матрицу. И процесс получения партнером каталога в разрезе всех магазинов занимает много времени. Сейчас мы прорабатываем это направление и внедряем механизмы кеширования данных, чтобы обмениваться уже только изменениями.
Первое время после запуска у нас также были сложности из-за человеческого фактора. Наши сборщики могли вместо клюквенного морса положить брусничный, заказ уходил к партнеру, а он не мог его принять, потому что этого морса не было в первоначальном заказе. С этой проблемой нам помогли справиться ребята, которые у нас занимаются фронтом: они прямо на кассах запретили замену товара для определенных партнеров.
В целом можно сказать, что у нас получилась полноценная интеграция с двумя самыми крупными службами. Да, есть над чем работать, но главная функциональность — прием и доставка заказа — работает довольно успешно.
Другие интеграции
Одной из главных целей нашей общей работы — максимально эффективная доставка товара, точнее, минимизация времени жизни заказа с момента наполнения корзины в приложении и до момента, когда заказ окажется у двери клиента. Поэтому мы интегрировались не только с партнерами-маркетплейсами, но и со службами доставки — Gett, Яндекс Такси, а также службой Net Fi.
Здесь нам важно определить возможность пешей или автомобильной доставки в зависимости от двух важных критериев: расстояния и веса заказа. Например, есть конкурс служб доставки, которым мы можем отдать заказ. Это может быть как наша внутренняя служба доставки, так и внешняя. И здесь можно настраивать в зависимости от приоритета одной службы перед другими, либо в разрезе магазинов и прочего.
Естественно, не бывает такого, чтобы две совершенно разные системы вошли в пазы друг друга как по маслу. Например, был вопрос с форматом адресов. Кому-то обязательно нужно, чтобы отдельно выделялись подъезд, квартира и этаж, а кому-то достаточно указать все это в комментарии. Опять же, авторизация и личный кабинет у каждой службы работает по-своему.
И как правило, API не всегда описывает все возможные случаи, которые могут произойти в процессе промышленной эксплуатации. Поэтому бэклог у нас полон, но нет таких задач, для которых не находится решение.
Команда
Как всегда, за любым процессом стоят люди. Мы в Автомаконе считаем, что для реализации непосредственно технической части интеграции с внешним партнером хватит трех человек: аналитика, специалиста по PHP, который пишет аутентификацию с партнером и все методы, обрабатывает запросы партнера и прочее, и программиста SQL, который полученную информацию раскладывает по нужным таблицам и так же по запросу партнера, транслируемому через через PHP в корневую процедуру, возвращает ему нужную информацию. Собственно, в таком составе мы и работаем.
Иногда возникают ситуации, в которых нам нужна помощь коллег. Тогда мы можем взять «напрокат» специалиста из той области, в которой у нас произошел затык. Такой обмен работает в обе стороны и помогает нам быстрее добиваться результатов.
Мы работаем по Agile: три раза в неделю проводим утренние стендапы по задачам и их статусам, определяя их приоритеты, проводим встречи с заказчиками и ретроспективы у команд. В общем, весь тот классический набор, который подразумевает эта методология, старались не придумывать чего-то своего и не переписывать Agile под себя…
Интеграция с внешними партнерами — это только верхушка айсберга. Есть еще интеграция с контрагентами, поставщиками, нашим сайтом и мобильным приложением. Сейчас мы идем по пути распределения информации между базами, и интеграции внутри компании тоже стали востребованы. Во весь этот процесс у нас вовлечены 13-14 человек, плюс люди из управления электронной коммерции, которые нам ставят задачи. А мы, в свою очередь, выбираем методы их реализации.
При этом сказать, что интеграционный процесс — это работа одной, хоть и большой, команды, нельзя. За работой всей системы в целом стоит множество команд, отвечающих за фронт, архитектуру системы, структуру наших внутренних документов и другие важные вещи.
Не стоит забывать и об админке, где можно посмотреть любой заказ, время его создания, проследить его путь и узнать службу, которая этот заказ будет доставлять. Также через админку мы передаем информацию о такси: номер автомобиля, имя таксиста и прочее.
Что ещё
Интеграция с внешними партнерами — сложный процесс, во многом потому что здесь не все зависит от разработчика. Партнеры — это два больших бизнеса, и чтобы внести какие-то изменения в процесс, нужно приложить много усилий всем сторонам. Да, работа с весовыми товарами все еще далека от идеала и требует доработки. Но интеграции уже проведены, мы их развиваем и заказы приезжают к клиентам. И я очень надеюсь, что большинство из них довольны.
Параллельно мы развиваем совершенно новое для нас направление, которое считаем перспективным.
Здесь перед нами открывается внушительный спектр задач. Проектирование каталогов и размещение данных в ситуации, когда мы одновременно и сами выступаем маркетплейсом, который принимает товары, и отдаем сторонним партнерам информацию о себе. Возникают мощные потоки данных, которыми нужно грамотно управлять.
Глобально для «ВкусВилла» приоритетная задача сейчас — это оптимизация механизмов доставки товаров до конечного покупателя. Наша команда также вовлечена в этот процесс и работает над геомодулем, который определяет самый оптимальный путь и способ доставки корзины покупателя в зависимости от ассортимента.
Это огромный блок задач, куда входит и работа с координатами, и оптимизация маршрутов, учет городского трафика и расчет оптимальной нагрузки на службу доставки. Которые тоже нужно совершенствовать.
О чем из внутренней работы вам было бы ещё интересно почитать?