Как на авито удалить аккаунт к которому привязан номер: Как удалить аккаунт на Авито?

Как удалить аккаунт на Авито?

QQROOZA
ЕКАТЕРИНА ОСИНОВСКАЯ

Содержание

• Введение
• Удаляем профиль Авито с компьютера
• Удаляем профиль Авито с телефона
• Другие статьи
• Кто вы вообще такие?

Введение

Меня зовут Екатерина Осиновская, я руководитель отдела клиентского сервиса компании QQROOZA.

Представляю вам свой цикл статей, который поможет вам детально разобраться с интерфейсом площадки Авито.

Эта статья познакомит с инструкцией по удалению аккаунта Авито.
Приятного чтения!

Удаляем профиль Авито с компьютера

Для того, чтобы удалить аккаунт Авито, лучше всего использовать полную (десктопную) версию сайта.
Для этого перейдите в раздел Настройки в профиле Авито:

Прокрутите страницу чуть ниже и отключите все подключенные у Вас уведомления, переместив переключатели таким образом, чтобы они стали подсвечиваться серым цветом.


Далее переходим в самый низ страницы, к опции “Удаление профиля”, нажимаем “Удалить”. Авито попросит указать причину удаления аккаунта, выбираем любую из представленного списка.


Обратите внимание, что при удалении аккаунта Авито, нельзя будет в течение 30 дней использовать номер, который был прикреплен к этому профилю, для создания нового аккаунта, а также после удаления данные восстановить будет уже невозможно. Площадка предупредит об этих нюансах перед окончательным удалением профиля.


Удаляем профиль Авито с телефона

Удалить профиль Авито через приложение невозможно, а вот через браузер смартфона – вполне, просто перейдя на полную версию сайта и повторив аналогичную процедуру. Для смартфонов на iOS и Android действуют разные алгоритмы для попадания на полноценный сайт.

IOS (браузер Safari)

Необходимо открыть настройки профиля через соответствующий значок слева в графе поиска. Далее перейти в “Настройки” и выбрать опцию “Полная версия”.

Android (браузер Google Chrome)

Полная версия сайта открывается не через настройки сайта Авито, а через настройки самого браузера.

Остальные статьи из цикла об интерфейсе площадки:

Цикл статей о продвижении на Авито:

Несколько наших кейсов:

Агентство QQROOZA

Агентство QQROOZA – эффективная команда молодых и креативных профессионалов, которая обеспечит вам комфортное взаимодействие и высокий, а главное полностью прозрачный результат от вложенного вами рекламного бюджета. Наша задача – сделать так, чтобы каждый вложенный вами рубль приносил вам прибыль.

В наши услуги входит:

· Проведение аудита и конкурентного анализа вашего бизнеса на Авито
· Создание и правильное оформление магазина на Авито
· Составление продающих текстов
· Создание качественных уникальных объявлений
· Подбор и редактирование фотографий для объявлений
· Своевременный ежедневный постинг ваших объявлений
· Корректировка рейтинга вашего магазина
· Переговоры и решение конфликтных ситуаций с поддержкой площадки
· Гарантия на случай блокировки
· Помощь в интеграции Авито с вашей CRM системой
· Еженедельный отчет по 22 показателям вашей рекламной кампании
· Ежедневный краткий отчет за прошедший день продвижения

Оставьте заявку прямо сейчас

и получите бесплатный аудит и конкурентный анализ вашей ниши на Авито

Как удалить аккаунт на Авито?

Дата публикации: 09. 06.2020

Когда люди успешно реализуют необходимые товары через Avito, у них нередко возникает желание и/или необходимость закрыть свой профиль на этом сайте. Задача это несложная, всего за несколько минут решается без труда.

Содержание страницы

• 1 Как удалить профиль на Авито, при стандартной регистрации – через e-mail?
• 2 Как удалить учетную запись Авито, если регистрировались через социальные сети?
• 3 Как удалить аккаунт на Авито, если он заблокирован администрацией Авито?

В 2020 году сервис Авито отключил возможность самостоятельного удаления профиля! В настоящее время, удалить профиль можно только через обращение в службу поддержки:Тема обращения / Действия с профилем / Удалить профиль.

Она немного усложняется лишь тогда, когда регистрация проводилась через соцсети или на учётную запись наложила блокировку администрация Авито. Ниже предлагается подробная инструкция, которая рассматривает удаление аккаунта даже в таких ситуациях.

Как удалить профиль на Авито, при стандартной регистрации – через e-mail?

Итак, это основной вариант, который предполагается для пользователейс активным аккаунтом и привязанным к нему e-mail, без дополнительных усложняющих обстоятельств.

Последовательность действий следующая:

1. Перейти на сайт Авито.
2. Войти в свою учётную запись через электронный адрес (либо телефон) и пароль. Если вы забыли верную комбинацию, то используйте возможность «Забыли пароль?», чтобы восстановить его.
3. В боковом меню нужно выбрать «Настройки».
4. Страницу проскроллить вниз, нажать на «Перейти к удалению учетной записи».
5. Появится предупреждение, что можно лишиться всей информации в профиле, даже размещённых объявлений. Если вы подтвердите действие, то восстановить информацию не получится. Можно будет указать причину такого решения. Если вы уверены, то нажмите «Удалить»!

Всё! Учётная запись полностью удаляется. При этом Авито заблокирует регистрацию с теми же телефоном и электронной почтой на полгода.


Как удалить учетную запись Авито, если регистрировались через социальные сети?

Использование соцсетей удобно возможностью экономии времени и получения доступа к личному кабинету без необходимости вводить информацию о себе.

При таком варианте авторизации способ удаления профиля на Авито получается немного другим. Нужна исходная привязка к электронной почте, иначе в разделе «Настройки» не будет надписи о переходе к удалению.

А так как вы изначально регистрировались упрощённо, то и электронную почту, предположительно, не вводили. Но волноваться не следует – исправить ситуацию легко, просто потребуется немного больше времени.

Здесь последовательность действий должна быть такая:

1. Перейдите на главную страницу.
2. Авторизуйтесь с помощью социальной сети.
3. Переместитесь в настройки.
4. В строке «Электронная почта» укажите свой e-mail адрес.
5. Внизу нажимайте «Сохранить».
6. На жёлтом фоне появится сообщение, что адрес следует активировать. Нажимайте «Выслать письмо».
7. Открывайте свою электронную почту и проверяйте. Сервис Авито должен был автоматически сгенерировать письмо и прислать. Если вы не видите его в основной папке, не стоит сразу беспокоиться – попробуйте проверить в папке «Спам».
8. Открыв письмо, изучите текст и перейдите по ссылке. Сервис должен будет проинформировать, что процедура завершена успешно, а e-mail, соответственно, подтверждён.

Теперь аккаунт можно удалять соответственно первому способу.


Как удалить аккаунт на Авито, если он заблокирован администрацией Авито?

Если будет иметь место нарушение правил, то администрация заблокирует аккаунт. Его владелец потеряет доступ к учётной записи и ничего не сможет в ней сделать (в том числе и удалить). Чтобы разобраться с ситуацией, профиль нужно будет заранее разморозить. Это делается так:

1. Щёлкните на ссылку https://support. avito.ru/articles/200027448.
2. Если всё правильно, то вы должны будете увидеть информацию насчёт блокировки и причин, по которым были заблокированы.
3. Внизу страницы будет ссылка, по которой можно создать обращение в техническую поддержку. Воспользуйтесь ей.
4. Выбирайте «Блокировки и отключения», а потом «Заблокированная учётная запись».

Указывайте проблему. Если нужно, сделайте прикрепление файла с доказательствами. Потребуется указать e-mail (не обязательно тот, которым вы пользовались при регистрации), а также имя. Вводите с картинки проверочный код, жмите «Отправить сообщение».

Администрация изучит информацию и по почте сообщит вам о решении. В случае, если аккаунт будет разблокирован, то дальше пользуйтесь либо первым, либо вторым способом удаления профиля – в зависимости от того, привязан у вас уже электронный адрес к аккаунту или нет.

Информация выше (как хочется надеяться) максимально понятно и подробно раскрывает процедуру удаления аккаунта Авито.

• Проще всего это сделать при изначальной регистрации через электронную почту.
• Если вход происходил через соцсети, нужно, первым делом, привязать к аккаунту свой e-mail.
• А вот для удаления заблокированного профиля нужно будет ещё и сперва восстановить доступ.

Политика конфиденциальности и использования файлов cookie – Avito Knitwear

​В бутике Avito Knitwear мы очень серьезно относимся к вашей конфиденциальности и безопасности, поэтому вы можете делать покупки с уверенностью, зная, что ваша конфиденциальность защищена.​​

Мы стремимся уважать и защищать ваши конфиденциальность, и мы гарантируем, что мы не будем продавать или передавать вашу личную информацию сторонним компаниям или третьим лицам, за исключением случаев, когда это необходимо для выполнения вашего запроса, например. для обработки оплаты и отправки/доставки вашего заказа. Мы выбираем Stripe для обработки вашего платежа и An Post для доставки вашего заказа. Оба полностью соответствуют GDPR.

Нам нужны ваши контактные данные, чтобы выполнить ваш заказ и поддерживать связь в случае возникновения каких-либо проблем или если вы решите подписаться на нашу рассылку.

Ваша личная информация и информация о заказах хранятся в защищенной базе данных, защищенной паролем, доступ к которой предоставляется только уполномоченному персоналу.

Ни при каких обстоятельствах мы не будем хранить данные вашей кредитной карты в файле.

Мы полностью соблюдаем GDPR (Общее положение о защите данных), вступившее в силу 25 мая 2018 года.

Пожалуйста, ознакомьтесь с подробной Политикой конфиденциальности/куки-файлов ниже.

Политика конфиденциальности/Политика в отношении файлов cookie

Последнее обновление: 20 мая 2021 г.

Настоящая Политика конфиденциальности описывает наши политики и процедуры в отношении сбора, использования и раскрытия вашей информации при использовании вами Сервиса и сообщает вам о ваших правах на конфиденциальность. и как закон защищает Вас.

Мы используем Ваши Персональные данные для предоставления и улучшения Сервиса. Используя Сервис, Вы соглашаетесь на сбор и использование информации в соответствии с настоящей Политикой конфиденциальности.

Интерпретация

Слова, в которых начальная буква написана с заглавной буквы, имеют значения, определяемые при следующих условиях. Следующие определения имеют одинаковое значение независимо от того, стоят ли они в единственном или во множественном числе.

Определения

Для целей настоящей Политики конфиденциальности:

Учетная запись означает уникальную учетную запись, созданную для Вас для доступа к нашему Сервису или его частям.

Компания (именуемая в настоящем Соглашении «Компания», «Мы», «Нас» или «Наш») относится к Avito Knitwear, The dunes Somerville, Tramore co Waterford.

Файлы cookie  – это небольшие файлы, размещаемые веб-сайтом на Вашем компьютере, мобильном устройстве или любом другом устройстве, которые содержат сведения о Вашей истории посещений этого веб-сайта среди множества его использований.

Страна относится к: Ирландия

Устройство означает любое устройство, которое может получить доступ к Сервису, такое как компьютер, мобильный телефон или цифровой планшет.

Персональные данные — это любая информация, относящаяся к идентифицированному или идентифицируемому физическому лицу.

Услуга относится к Веб-сайту.

Поставщик услуг означает любое физическое или юридическое лицо, которое обрабатывает данные от имени Компании. Это относится к сторонним компаниям или физическим лицам, нанятым Компанией для содействия Услуге, для предоставления Услуги от имени Компании, для оказания услуг, связанных с Услугой, или для помощи Компании в анализе того, как используется Услуга.

Данные об использовании относятся к данным, собираемым автоматически, либо сгенерированным при использовании Сервиса, либо из самой инфраструктуры Сервиса (например, продолжительность посещения страницы).

Веб-сайт относится к AvitoKnitwear, доступ к которому можно получить с www. AvitoKnitwear.ie

Вы означаете физическое лицо, осуществляющее доступ или использующее Сервис, или компанию, или другое юридическое лицо, от имени которого такое физическое лицо осуществляет доступ или использует Сервис , применимо.

Сбор и использование ваших персональных данных

Типы собираемых данных
Персональные данные

При использовании нашего Сервиса мы можем попросить вас предоставить нам определенную личную информацию, которая может быть использована для связи или идентификации вас . Личная информация может включать, но не ограничивается:

Адрес электронной почты

Имя и фамилия

Номер телефона

Адрес, штат, округ, почтовый индекс, город

Данные об использовании

Данные об использовании

Данные об использовании собираются автоматически при использовании Сервиса.

Данные об использовании могут включать в себя такую ​​информацию, как адрес интернет-протокола вашего устройства (например, IP-адрес), тип браузера, версия браузера, страницы нашего Сервиса, которые вы посещаете, время и дата вашего посещения, время, проведенное на этих страницах, уникальные идентификаторы устройств и другие диагностические данные.

Когда вы получаете доступ к Сервису с мобильного устройства или через него, Мы можем автоматически собирать определенную информацию, включая, помимо прочего, тип используемого вами мобильного устройства, уникальный идентификатор вашего мобильного устройства, IP-адрес вашего мобильного устройства, Ваша мобильная операционная система, тип используемого мобильного интернет-браузера, уникальные идентификаторы устройств и другие диагностические данные.

Мы также можем собирать информацию, которую ваш браузер отправляет всякий раз, когда вы посещаете наш Сервис или когда вы получаете доступ к Сервису с помощью мобильного устройства.

Технологии отслеживания и куки-файлы

Мы используем куки-файлы и аналогичные технологии отслеживания для отслеживания активности в Нашей Службе и хранения определенной информации. Используемые технологии отслеживания — это маяки, теги и сценарии для сбора и отслеживания информации, а также для улучшения и анализа Нашего Сервиса. Используемые нами технологии могут включать:

•         Файлы cookie или файлы cookie браузера. Файл cookie — это небольшой файл, размещенный на Вашем Устройстве. Вы можете указать своему браузеру отказаться от всех файлов cookie или указать, когда отправляется файл cookie. Однако, если вы не принимаете файлы cookie, вы не сможете использовать некоторые части нашего Сервиса. Если вы не изменили настройки своего браузера таким образом, чтобы он отказывался от файлов cookie, наша Служба может использовать файлы cookie.
•         Флэш-куки. Некоторые функции нашего Сервиса могут использовать локальные сохраненные объекты (или файлы Flash Cookies) для сбора и хранения информации о ваших предпочтениях или вашей активности в нашем Сервисе. Flash-куки не управляются теми же настройками браузера, что и для браузерных куки-файлов. Для получения дополнительной информации о том, как можно удалить Flash Cookies, ознакомьтесь с разделом «Где я могу изменить настройки для отключения или удаления локальных общих объектов?» доступно по адресу https://helpx. adobe.com/flash-player/kb/disable-local-shared-objects-flash.html#main_Where_can_I_change_the_settings_for_disabling__or_deleting_local_shared_objects_
•         Веб-маяки. Некоторые разделы нашего Сервиса и наши электронные письма могут содержать небольшие электронные файлы, известные как веб-маяки (также называемые прозрачными GIF-файлами, пиксельными тегами и однопиксельными GIF-файлами), которые позволяют Компании, например, подсчитывать пользователей, посетивших эти страниц или открытия электронной почты, а также для другой связанной статистики веб-сайта (например, запись популярности определенного раздела и проверка целостности системы и сервера).

Файлы cookie могут быть «постоянными» или «сеансовыми». Постоянные файлы cookie остаются на вашем персональном компьютере или мобильном устройстве, когда вы выходите из сети, а сеансовые файлы cookie удаляются, как только вы закрываете свой веб-браузер. Узнайте больше о файлах cookie: что такое файлы cookie?.

Мы используем как сеансовые, так и постоянные файлы cookie для целей, изложенных ниже:

Необходимые / основные файлы cookie

Тип: сеансовые файлы cookie

Управляется: нами

Цель: эти файлы cookie необходимы для предоставления вам доступных услуг через Веб-сайт и чтобы вы могли использовать некоторые из его функций. Они помогают аутентифицировать пользователей и предотвращают мошенническое использование учетных записей пользователей. Без этих файлов cookie услуги, о которых вы просили, не могут быть предоставлены, и мы используем эти файлы cookie только для предоставления вам этих услуг.

Политика в отношении файлов cookie / Уведомление о принятии файлов cookie

Тип: постоянные файлы cookie

Управляется: нами

Цель: эти файлы cookie определяют, согласились ли пользователи на использование файлов cookie на веб-сайте.

Функциональные файлы cookie

Тип: Постоянные файлы cookie

Администрируется: Мы

Назначение: Эти файлы cookie позволяют нам запоминать выбор, который вы делаете при использовании Веб-сайта, например, запоминание ваших регистрационных данных или языковых предпочтений. Цель этих файлов cookie — предоставить вам более персонализированный опыт и избавить вас от необходимости повторно вводить свои предпочтения каждый раз, когда вы используете веб-сайт.

Файлы cookie для отслеживания и производительности

Тип: Постоянные файлы cookie

Администрируются: Третьи стороны

Назначение: Эти файлы cookie используются для отслеживания информации о трафике на Веб-сайте и о том, как пользователи используют Веб-сайт. Информация, собранная с помощью этих файлов cookie, может прямо или косвенно идентифицировать вас как отдельного посетителя. Это связано с тем, что собранная информация обычно связана с псевдонимом, связанным с устройством, которое вы используете для доступа к Веб-сайту. Мы также можем использовать эти файлы cookie для тестирования новых страниц, функций или новых функций Веб-сайта, чтобы увидеть, как наши пользователи реагируют на них.

Для получения дополнительной информации о файлах cookie, которые мы используем, и вашем выборе файлов cookie посетите нашу Политику использования файлов cookie или раздел «Файлы cookie» нашей Политики конфиденциальности.

Использование ваших личных данных

Компания может использовать личные данные для следующих целей:

Для предоставления и обслуживания нашего Сервиса , в том числе для мониторинга использования нашего Сервиса.

Для управления Вашей Учетной записью: для управления Вашей регистрацией в качестве пользователя Сервиса. Предоставляемые вами Персональные данные могут предоставить вам доступ к различным функциям Сервиса, которые доступны вам как зарегистрированному пользователю.

Для выполнения договора: разработка, соблюдение и заключение договора купли-продажи продуктов, предметов или услуг, которые вы приобрели, или любого другого договора с Нами через Сервис.

Для связи с Вами: Для связи с Вами по электронной почте, телефонным звонкам, SMS или другим эквивалентным формам электронной связи, таким как push-уведомления мобильного приложения об обновлениях или информационные сообщения, связанные с функциями, продуктами или контрактными услугами, включая обновления безопасности, когда это необходимо или целесообразно для их реализации.

Для предоставления Вам новостей, специальных предложений и общей информации о других товарах, услугах и событиях, которые мы предлагаем, которые аналогичны тем, которые вы уже приобрели или о которых спрашивали, если вы не решили не получать такую ​​информацию.

Для управления вашими запросами: Для обслуживания и управления вашими запросами к Нам.

Для передачи бизнеса: Мы можем использовать вашу информацию для оценки или проведения слияния, отделения, реструктуризации, реорганизации, роспуска или другой продажи или передачи некоторых или всех Наших активов, будь то в качестве действующего предприятия или как часть банкротство, ликвидация или аналогичная процедура, в рамках которой Персональные данные, хранящиеся у Нас о пользователях нашего Сервиса, входят в число передаваемых активов.

Для других целей : Мы можем использовать вашу информацию для других целей, таких как анализ данных, выявление тенденций использования, определение эффективности наших рекламных кампаний, а также для оценки и улучшения нашего Сервиса, продуктов, услуг, маркетинга и вашего опыта.

Мы можем передавать вашу личную информацию в следующих ситуациях:

•         Поставщикам услуг: Мы можем передавать вашу личную информацию Поставщикам услуг для мониторинга и анализа использования нашего Сервиса, для обработки платежей, для связи с вами.
•         Для передачи бизнеса: Мы можем делиться или передавать вашу личную информацию в связи или во время переговоров о любом слиянии, продаже активов Компании, финансировании или приобретении всего или части Нашего бизнеса другой компании.
•         С аффилированными лицами: Мы можем делиться вашей информацией с Нашими аффилированными лицами, и в этом случае мы потребуем от этих аффилированных лиц соблюдения настоящей Политики конфиденциальности. К аффилированным лицам относятся наша материнская компания и любые другие дочерние компании, партнеры по совместным предприятиям или другие компании, которые мы контролируем или которые находятся под общим с нами контролем.
•         С деловыми партнерами: Мы можем делиться вашей информацией с Нашими деловыми партнерами, чтобы предлагать вам определенные продукты, услуги или рекламные акции.
•         С другими пользователями: когда вы делитесь личной информацией или иным образом взаимодействуете в общедоступных местах с другими пользователями, такая информация может быть просмотрена всеми пользователями и может быть публично распространена за ее пределами.
•         С вашего согласия : Мы можем раскрывать вашу личную информацию для любых других целей с вашего согласия.
Хранение ваших личных данных

Компания будет хранить ваши личные данные только до тех пор, пока это необходимо для целей, изложенных в настоящей Политике конфиденциальности. Мы будем хранить и использовать ваши персональные данные в объеме, необходимом для выполнения наших юридических обязательств (например, если мы обязаны хранить ваши данные в соответствии с действующим законодательством), разрешать споры и обеспечивать соблюдение наших юридических соглашений и политик.

Компания также будет хранить данные об использовании для целей внутреннего анализа. Данные об использовании, как правило, хранятся в течение более короткого периода времени, за исключением случаев, когда эти данные используются для усиления безопасности или улучшения функциональности Нашего Сервиса, или когда мы по закону обязаны хранить эти данные в течение более длительных периодов времени.

Передача Ваших Персональных Данных

Ваша информация, включая Персональные Данные, обрабатывается в операционных офисах Компании и в любых других местах, где находятся стороны, участвующие в обработке. Это означает, что эта информация может передаваться и храниться на компьютерах, расположенных за пределами вашего штата, провинции, страны или другой государственной юрисдикции, где законы о защите данных могут отличаться от законов вашей юрисдикции, например. международная отправка.

Ваше согласие с настоящей Политикой конфиденциальности, за которым следует предоставление такой информации, означает Ваше согласие на эту передачу.

Компания предпримет все разумно необходимые шаги для обеспечения безопасного обращения с вашими данными в соответствии с настоящей Политикой конфиденциальности, и никакая передача ваших личных данных не будет осуществляться организации или стране, если не будут приняты надлежащие меры контроля, включая безопасность Ваших данных и другой личной информации.

Раскрытие ваших личных данных
Деловые операции

Если Компания участвует в слиянии, поглощении или продаже активов, ваши личные данные могут быть переданы. Мы уведомим вас до того, как ваши Персональные данные будут переданы и станут предметом другой Политики конфиденциальности.

Правоохранительные органы

При определенных обстоятельствах Компания может быть обязана раскрыть Ваши Персональные данные, если это требуется по закону или в ответ на действительные запросы государственных органов (например, суда или государственного учреждения).

Другие юридические требования

Компания может раскрывать Ваши Персональные данные, добросовестно полагая, что такие действия необходимы для:

•         Выполнения юридического обязательства
•         Защита прав или собственности Компании
• 6
• 6
• 6        Предотвращение или расследование возможных правонарушений в связи с Сервисом
•         Защита личной безопасности Пользователей Сервиса или общества
•         Защита от юридической ответственности
Безопасность ваших личных данных

Безопасность ваших личных данных важна для нас, но помните, что ни один метод передачи через Интернет или метод электронного хранения не является безопасным на 100%. Хотя мы стремимся использовать коммерчески приемлемые средства для защиты ваших личных данных, мы не можем гарантировать их абсолютную безопасность.

Подробная информация об обработке ваших персональных данных

Поставщики услуг, которых мы используем, могут иметь доступ к вашим персональным данным. Эти сторонние поставщики собирают, хранят, используют, обрабатывают и передают информацию о ваших действиях в Нашем Сервисе в соответствии с их Политикой конфиденциальности.

Analytics

Мы можем использовать сторонних поставщиков услуг для мониторинга и анализа использования нашего Сервиса.

Google Analytics

Google Analytics — это служба веб-аналитики, предлагаемая Google, которая отслеживает и сообщает о трафике веб-сайта. Google использует собранные данные для отслеживания и мониторинга использования нашего Сервиса. Эти данные передаются другим службам Google. Google может использовать собранные данные для контекстуализации и персонализации рекламы своей собственной рекламной сети.

Вы можете отказаться от того, чтобы сделать вашу деятельность в Сервисе доступной для Google Analytics, установив надстройку браузера для отказа от Google Analytics. Надстройка не позволяет JavaScript-коду Google Analytics (ga.js, analytics.js и dc.js) обмениваться информацией о посещениях с Google Analytics.

Для получения дополнительной информации о политике конфиденциальности Google посетите веб-страницу конфиденциальности и условий Google: https://policies.google.com/privacy

Маркетинг по электронной почте

Мы можем использовать ваши персональные данные для связи с вами с информационными бюллетенями, маркетинговыми или рекламными материалами и другой информацией, которая может вас заинтересовать. Вы можете отказаться от получения каких-либо или всех этих сообщений от Нас, перейдя по ссылке для отказа от подписки или инструкциям, приведенным в любом электронном письме, которое Мы отправляем, или связавшись с Нами.

Мы можем использовать поставщиков услуг электронного маркетинга для управления и отправки вам электронных писем.

Mailchimp

Mailchimp — это служба рассылки электронных писем, предоставляемая The Rocket Science Group LLC.

Для получения дополнительной информации о политике конфиденциальности Mailchimp, пожалуйста, посетите их политику конфиденциальности: https://mailchimp.com/legal/privacy/

Платежи

Мы можем предоставлять платные продукты и/или услуги в рамках Сервиса. В этом случае мы можем использовать сторонние сервисы для обработки платежей (например, платежные системы).

Мы не будем хранить или собирать данные вашей платежной карты. Эта информация предоставляется непосредственно Нашим сторонним платежным системам, чье использование вашей личной информации регулируется их Политикой конфиденциальности. Эти платежные системы придерживаются стандартов, установленных PCI-DSS и управляемых Советом по стандартам безопасности PCI, который является совместным усилием таких брендов, как Visa, Mastercard, American Express и Discover. Требования PCI-DSS помогают обеспечить безопасную обработку платежной информации.

Stripe

С их Политикой конфиденциальности можно ознакомиться по адресу https://stripe.com/us/privacy

Конфиденциальность детей

Наша служба не адресована лицам моложе 13 лет. Мы сознательно не собираем личную информацию от любого лица в возрасте до 13 лет. Если вы являетесь родителем или опекуном и вам известно, что ваш ребенок предоставил нам персональные данные, пожалуйста, свяжитесь с нами. Если нам станет известно, что мы собрали Персональные данные от любого лица в возрасте до 13 лет без проверки согласия родителей, мы предпримем шаги для удаления этой информации с наших серверов.

Если нам необходимо полагаться на согласие как на юридическое основание для обработки вашей информации, а в вашей стране требуется согласие родителя, мы можем потребовать согласия вашего родителя, прежде чем собирать и использовать эту информацию.

Ссылки на другие веб-сайты

Наш Сервис может содержать ссылки на другие веб-сайты, которыми мы не управляем. Если вы нажмете на стороннюю ссылку, вы будете перенаправлены на сайт этой третьей стороны. Мы настоятельно рекомендуем вам ознакомиться с Политикой конфиденциальности каждого сайта, который вы посещаете.

Мы не контролируем и не несем ответственности за содержание, политику конфиденциальности или действия любых сторонних сайтов или служб.

Изменения в настоящей Политике конфиденциальности

Мы можем время от времени обновлять нашу Политику конфиденциальности. Мы сообщим Вам о любых изменениях, опубликовав новую Политику конфиденциальности на этой странице.

Мы сообщим Вам об этом по электронной почте и/или в виде заметного уведомления в Нашей Службе до того, как изменение вступит в силу, и обновим дату «Последнее обновление» в верхней части настоящей Политики конфиденциальности.

Рекомендуется периодически просматривать настоящую Политику конфиденциальности на предмет любых изменений. Изменения настоящей Политики конфиденциальности вступают в силу с момента их публикации на этой странице.

Свяжитесь с нами

Если у вас есть какие-либо вопросы об этой Политике конфиденциальности, вы можете связаться с нами:

По электронной почте: [email protected]

Посетив эту страницу на нашем веб-сайте: www.AvitoKnitwear.ie система управления в Авито | Фрол Крючков | AvitoTech

Каждая классификация в какой-то момент своего роста сталкивается с проблемой систематизации, упорядочивания и организации своих метаданных. Почему это так важно? Чтобы ответить на этот вопрос, нам нужно понять несколько основных вещей о метаданных и о том, как они используются.

Скорее всего, вы уже работали с метаданными. Я приведу короткий пример, чтобы вы могли получить представление. Предположим, у вас есть сайт, на котором пользователи могут публиковать информацию о том, что они продают. Чтобы опубликовать рекламу, продавец заполняет определенные поля, такие как название , категория , цена , местоположение, и т. д. Эти поля, значения списка и типы значений, которые могут заполнять пользователи, являются метаданными. Проще говоря, это данные о данных.

Рисунок 1. Примеры метаданных: название, категория, цена, описание объявления

После того, как продавец подал объявление, ему необходимо оплатить размещение. Эти листинговые сборы обычно основаны на информации в объявлении. Например, цена автомобиля может существенно различаться в зависимости от года выпуска и марки. Или это может быть местоположение, которое больше всего влияет на листинговые сборы. Не очевидно, что скорость и плавность изменения метаданных компании станут узким местом для поиска стратегий монетизации путем проведения A/B-тестов.

Рисунок 2. Использование метаданных в бизнесе

Менее очевидный пример — когда метаданные помогают настроить SEO. Не секрет, что чем больше органического трафика у сайта, тем лучше для бизнеса. Страницы результатов поисковой системы (SERP) и рекламные страницы являются самыми популярными страницами в объявлениях. Рекламные страницы менее интересны, поэтому я опишу случай SERP.

Пользователи могут использовать миллионы комбинаций фильтров. Каждая комбинация фильтров дает уникальную поисковую выдачу. И это плохо для SEO, когда тонны поисковых запросов пользователей разбросаны по тоннам поисковой выдачи, потому что вес каждой страницы мал. Чтобы решить эту проблему, появился канонический URL.

Один уникальный канонический URL группирует относительно похожие страницы и заставляет их считаться одной страницей для поисковых систем. Например, пользовательский поиск по всем автомобилям старше пяти лет попадет в один канонический URL «5-year-old-car», даже если пользователь укажет конкретную марку или цвет. Или критерий поиска: «дом напротив пляжа» с дополнительным фильтром типа коттедж или квартира значения не имеет; это будет «перед пляжем». Это простые примеры, но я думаю, что вы поняли идею. Повторюсь: чем быстрее ваша система позволит вам адаптироваться к меняющемуся миру, тем лучше.

На этом этапе вы можете применить один и тот же шаблон ко всем следующим полям:

• какие данные должен предоставить пользователь;
• какой тип метаданных, отображаемых в рекламе, приводит к лучшему CTR;
• обнаружение мошеннических списков;
• индексация;
• ценовое предложение;
• вы называете это.

Мы обсудили преимущества быстрого изменения метаданных. Но что мешает быстро изменить его?

Из рисунка 2 видно, что метаданные объединяют все домены приложения. Вот почему трудно внести изменения в какую-либо его часть. Даже незначительные изменения типа атрибута могут сломать всю систему. Например, изменение одного атрибута из списка значений в форме подачи объявления может нарушить алгоритмы поисковой индексации и монетизации.

Мы хотели, чтобы разные отделы легко принимали решения относительно своих метаданных без взаимодействия с другими отделами. В то же время отделы должны при необходимости синхронизировать метаданные между разными доменами. Например, когда мы хотим добавить обязательное поле в определенную категорию, не нарушая индексацию поиска или удаляя поля, используемые при расчете платы за листинг. Помня об этом, мы определили функциональные требования к нашей системе управления метаданными или информационной модели, как мы ее называем.

Функциональные требования:

• Решение должно предоставлять нашим инженерам и аналитикам возможность легко вносить изменения в метаданные, такие как добавление, удаление и обновление атрибутов и категорий, а также их типов, значений и параметров.
• Любые изменения в метаданных пространства конкретного отдела не должны влиять на метаданные других отделов. Если это невозможно, мы должны предупредить пользователей. Например, атрибуты для добавления на десктоп, iOS и Android с разными версиями, пространство атрибутов для поисковой индексации, модерации, поисковых фильтров и визуализации на разных платформах.
• Каждый отдел (доменное пространство) должен иметь возможность запускать несколько версий своих метаданных одновременно, т. е. для целей A/B-тестирования.

Нефункциональные требования:

• Система должна легко масштабироваться по горизонтали.
• Он должен эффективно использовать память и быть быстрым во время выполнения.
• Должна быть терпима к несоответствию версий.
• Удобно для работы в сети.

Самый простой способ хранить метаданные — встроить их в схему базы данных и жестко закодировать в кодовой базе. Чтобы показать это, мы приступим к нашему первому примеру. После того, как пользователь отправил рекламу, она будет сохранена в таблице базы данных со следующей схемой:

Рисунок 3. Схема таблицы для хранения рекламы

Не поймите меня неправильно. В данном случае это совершенно прекрасный способ сделать вашу схему, и я почти уверен, что в большинстве случаев он достаточно хорош. Однако в нашем случае нам нужно запустить несколько разных категорий. Каждая категория — это целая вертикаль в нашем бизнесе, и каждая вертикальная команда хочет экспериментировать в своей категории, добавляя, удаляя, изменяя столбцы.

Мы также хотим провести A/B-тестирование, добавив новое поле в определенную категорию, чтобы узнать, понравится ли оно пользователям. Это не будет проблемой, если вам не нужно изменить схему и добавить новое поле, что требует блокировки всей таблицы. Это довольно сложно, если вы запускаете базу данных с миллиардами рекламных объявлений. Даже если вы сегментируете базу данных по категориям, вам все равно потребуется выполнить миграцию, установить значения по умолчанию и т. д. Вторая проблема заключается в том, что для изменения вашей схемы требуется новая фиксация для изменения схемы базы данных и новое развертывание службы для выполнения миграции схемы. Это не та беглость, которую мы хотели.

Давайте представим один возможный способ организации схем базы данных, который не потребует от нас выполнения миграций для доставки новых атрибутов:

Рисунок 4. Вообразимое решение для динамических метаданных вокруг атрибутов рекламных объявлений

Ого, пять новых таблиц вместо одной, и еще пара не показаны для простоты. Но не бойтесь. Идея проста: мы превращаем наши столбцы в строки, а остальные — это вспомогательные таблицы для запуска системы. Этот подход называется моделью “сущность-атрибут-значение” (EAV) 9.0398 .

Так много новых таблиц в основном потому, что теперь наше приложение отвечает за обеспечение логической схемы. В старом подходе база данных отвечала за обеспечение согласованности данных с помощью внешних ключей. Подход EAV приводит нас к двум проблемам:

1. Наше приложение должно отвечать за согласованность данных.
2. При такой нормализованной схеме производительность во время выполнения сильно пострадает.

Другой подход заключается в использовании документно-ориентированного способа хранения структуры атрибутов и данных. Мы оспорили этот подход и пришли к выводу, что если бы мы сохраняли свойства и данные в каждом рекламном документе, это стоило бы нам слишком много памяти. И самое главное, работа со старыми документами в кодовой базе обременительна.

Мы не рассматривали графовые базы данных из-за отсутствия опыта в нашей компании.

Основные идеи, использованные при разработке нашей информационной модели, устарели и хорошо зарекомендовали себя — нормализация для согласованности, денормализация для производительности. Мы пошли по этому пути и придумали два глобальных компонента:

1. Система управления метаданными с дружественным пользовательским интерфейсом для управления вариациями шаблона EAV.
2. Фронтенд для бэкенда — высокопроизводительные микросервисы, выполняющие операции с данными во время выполнения. Они используют сильно денормализованный интерфейс данных для внутренней системы для проверки, подготовки к рендерингу и других целей.

После формирования этих глобальных компонентов возник шаблон EAV: как обеспечить согласованность данных на уровне приложения и ускорить его работу во время выполнения.

Рисунок 5. Основные элементы инфомодели

Ядро системы инфомодели состоит из двух основных элементов. Первый — это каталог категорий, атрибутов, значений и возможных отношений. Второй — макет, абстракция, состоящая из трех других элементов, о которых мы поговорим позже.

Каталог

Каталог представляет собой нормализованное хранилище категорий, атрибутов и значений в третьей нормальной форме. Он отражает архитектуру шаблона EAV, рассмотренную ранее, но только его атрибутивную часть. В каталоге есть список категорий, который является корнем для остальных атрибутов. Это список категорий, в которых работает наш бизнес, таких как аренда автомобилей, продажа автомобилей, продажа недвижимости, аренда недвижимости, краткосрочная аренда недвижимости и другие.

Далее идет каталог атрибутов. Атрибуты являются свойством категории. Например, это может быть марка , модель , год выпуска на аренду автомобиля . Для недвижимости это может быть город , район, или кв площадь. Значения являются всеми возможными значениями атрибутов перечислимого типа. Например, для атрибута марка категории авто возможные значения: audi, bmw или ford .

Также каталог отвечает за все возможные отношения между атрибутами и их значениями:

Рисунок 6. Формат отношений между атрибутами и значениями

Чтобы объяснить, почему нам все же нужно сохранить все возможные отношения, нам нужно перейти ко второму основному компоненту инфомодели — макету .

Макет

Макет представляет собой композицию из трех различных компонентов.

Макет

Макет — это имя для трех манифестов, описывающих поведение, структуру и свойства формы пространства имен. Компоненты макета решают одну проблему, имеющую две стороны:

• Возможность по-разному представлять одни и те же метаданные в разных пространствах имен.
• Изоляция одного пространства имен от других, чтобы одна команда могла изменять любые свойства поведения, структуры и свойств формы, не затрагивая другие пространства имен.

Отношения отвечают за определенную структуру данных в пространстве имен или макете, как мы называем это внутри. Проще показать на примере с рисунка 7:

Рисунок 7. Пример двух структур отношений одних и тех же метаданных

Как видите, есть две пользовательские истории, в которых мы используем одни и те же метаданные в разных схемах.

Первый случай – подача нового объявления о продаже автомобиля. В этом потоке самым коротким способом для пользователя указать свой автомобиль будет сначала выбрать марку, затем выбрать модель этой марки, затем указать год выпуска автомобиля и так далее. По мере того, как пользователь заполняет поля, становится меньше вариантов для выбора. Мы можем даже заполнить остальные поля автоматически на каком-то шаге, потому что остается только один вариант.

Другой пример: посетитель ищет автомобиль. Они обычно ищут с более широким диапазоном. Таким пользователям проще заполнить марку и модель и выбрать из списка 4–8 поколений, чем подбирать конкретные годы. В таких сценариях в игру вступают отношения. Используя несжатую структуру каталога с картинки 6, мы можем настроить любые отношения компоновки. Эта идея также широко используется при проверке входных данных пользователя.

Форма полей. Следующим элементом макета является форма полей. Этот компонент представляет собой декларативный способ описания полей, отображаемых для пользователя или для внутреннего бэкэнда.

Форма состоит из списка полей, которые связаны с определенными отношениями и атрибутами. Важно то, что здесь объявлены все конфигурации полей. Это означает, что семантически один и тот же атрибут может иметь разные свойства в разных макетах. Например, у нас есть атрибут бренда, и когда пользователь отправляет рекламу, поле выглядит как вход для выбора одной опции. Однако в форме поиска это поле с несколькими вариантами. Форма отвечает за:

• Список полей атрибутов формы.
• Связь между полями и фактическими атрибутами формы и каталогом.
• Свойства полей и самой формы.

Правила. Последний элемент макета — это манифест правила. Это декларативный DSL (предметно-ориентированный язык) для описания поведения полей формы. Этот компонент отвечает за отображение/скрытие, включение/отключение, проверку полей на основе состояния всей формы и даже изменение их свойств и состояний.

Вы можете увидеть результат этого элемента при выборе марки. Он запускает новое состояние формы, когда мы отображаем атрибут модели. Или другой пример, когда в выбранном городе есть метро, ​​мы покажем атрибут со станциями метро. Стоит отметить, что манифесты никто не пишет. Система управления метаданными создает их автоматически в пользовательском интерфейсе.

Управление версиями

Макеты — отличный способ различать разные платформы, домены и отделы. Однако, когда у каждого отдела есть свой набор макетов, они быстро понимают, что хотят запускать несколько версий одного и того же макета одновременно для A/B-тестов или когда мы объединяем старые версии мобильных приложений или внутренних сервисов.

Реализация управления версиями макетов концептуально ничем не отличается от системы контроля версий, такой как Git. Он использует систему ветвления. У нас есть сущности, которые могут меняться: каталоги и макеты (правила, отношения, формы). Мы также знаем, что у нас должна быть возможность запускать столько версий одного и того же макета, сколько у нас есть A/B-тестов.

Это приводит нас к реализации, в которой у вас есть ветки для различных A/B-тестов. Но чтобы использовать конкретную ветку, включая основную ветку, вы должны ее освободить. В момент релиза происходят две основные вещи.

Во-первых, серверная часть объединяет все изменения и выводит их в эффективный формат хранения, к которому можно легко получить доступ во время выполнения. Во-вторых, выпуск тега версии, сгенерированного для того, какая версия макета может быть доступна в производстве. Чтобы поддерживать актуальность метаданных A/B-тестов, вы можете объединить основную ветку. Слияние основной ветки с A/B-тестированием необходимо, поскольку после выпуска версии метаданных вы поддержали все объекты, включая те, которые вы даже не трогали. Это происходит потому, что мы решили реализовать стратегию только добавления, которая требует менее сложной реализации.

Маршрутизация

Прежде всего, что такое маршрутизация? Мы уже обсудили множество элементов, таких как версии и макеты. Маршрутизация была придумана для того, чтобы клиент (мобильное приложение, фронтенд-браузер, фронтенд-сервис) мог указать макет и версию для его использования.

Технически маршрутизация — это просто строка, по которой другие службы могут получить доступ к макетам. Он имеет шаблон: {версия}.{имя макета}.{категория}. В реальной жизни это выглядит так: REAL-123.new-adv-mobile.13. Тег версии обычно обозначает задачу Jira, в которой запрашиваются изменения. Однако, если вы хотите отладить макет в промежуточной версии, не выпуская новую версию, вы можете указать dev.real-123 в качестве имени тега. Тогда все спецификации будут генерироваться по запросу. Я не буду обсуждать, как это делается в этой статье, потому что это совсем другая тема.

Рисунок 8. Маршрутизация

Здесь менее очевидное наблюдение: наличие категории в маршруте обеспечивает максимальную степень детализации A/B-тестов. Это сделано специально. У каждого отдела или бизнес-вертикали есть своя «песочница» для проведения экспериментов без дублирования с другими отделами. Однако внутри маршрута все конфликтующие A/B-тесты должны быть соответствующим образом организованы внутри одного отдела.

Одна из основных целей новой системы управления метаданными заключалась в том, чтобы убедиться, что мы можем легко вносить новые изменения, в том числе несовместимые с предыдущими версиями. Это невозможно, если серверная часть обслуживает последнюю версию, потому что это приводит к тому, что мы предоставляем новую версию конечной точки для критических изменений. Огромной архитектуре сложно перейти на следующую версию API. Поэтому мы решили изменить эту парадигму и предоставить клиентам ту версию, которую они хотят.

Поскольку мы рассмотрели все компоненты, пришло время показать всю концепцию. Для этого я воспользуюсь аналогией с призмой. По крайней мере, это работает для меня, и я надеюсь, что это сработает и для вас. Итак, у вас есть золотой источник ваших каталогов метаданных. Также у вас есть макеты, которые представляют собой набор правил, форм и отношений. Идея довольно проста: различные макеты подобны призме, которая фильтрует и изменяет представление и поведение золотого источника каталогов.

Рисунок 9. Макеты как призма для определенных бизнес-доменов

Есть несколько важных вещей, которые макеты делают и не делают:

• Макет не отвечает за внешний вид форм. Он содержит структуру в виде шагов и свойств полей. Но он действует как конфигурация для интерфейса.
• Макет не всегда служит визуальным представлением чего-либо. Макет может быть механизмом проверки, представлением данных для внутреннего использования и т.п. Кроме того, макет может выступать в качестве механизма шаблонов для канонических URL-адресов поисковой выдачи.
• Одновременно можно использовать разные версии одного и того же макета. В основном это происходит с мобильными приложениями, в разных версиях которых используются старые API и A/B-тесты.

На этом этапе мы можем перейти к более техническим деталям:

Рисунок 10. Схема компонентов системы управления метаданными

В системе управления метаданными есть три основных уровня: серверная часть информационной модели, внешняя часть информационной модели. и бытовые услуги.

• Серверная часть отвечает за внесение изменений в метаданные, загрузку каталогов из внешних источников, выпуск новых версий.
• Внешний интерфейс отвечает за доступ в режиме реального времени к макетам, каталогам и атрибутам. Наиболее распространенные варианты использования: проверка формы для веб-сайта или мобильного устройства, сборка представления атрибутов для рекламы, сборка формы для рендеринга для веб-сайта или мобильного устройства.
• Потребительские услуги реализуют бизнес-логику. Это может быть интерфейс, мобильное приложение или внутренний сервис.

Серверная часть EAV для системы управления метаданными более или менее похожа на типичное веб-приложение. Он состоит из реляционной базы данных, одностраничного приложения и нескольких сложных ETL. Здесь вы можете управлять данными каталогов, правил и отношений, создавать макеты, создавать ветки, выпускать новые версии. Однако специфические вещи относятся к нашим внутренним инструментам, например автоматическое тестирование всей системы при внесении изменений в метаданные. Все эти выпуски новой версии информационной модели запускают ряд тестов E2E, чтобы убедиться, что наши пользователи по-прежнему могут добавлять или искать рекламу в каждой категории.

Рисунок 11. Одностраничное приложение бэкенда информационной модели

С технической точки зрения это сложное веб-приложение с большим количеством доменной логики и валидаторов. Они гарантируют, что все макеты, отношения, категории и атрибуты по-прежнему работают после применения изменений метаданных. Например, мы должны проверить, что нет циклических зависимостей, недостижимых состояний и так далее. Многое также происходит с генерацией макетов по запросу для отладки в промежуточной среде.

Реализация управления версиями

Стоит упомянуть, как управление версиями реализовано в базе данных. Мы много изучали управление версиями и решили использовать стратегию добавления журнала. Эта стратегия означает, что всякий раз, когда мы делаем даже малейшее изменение, например, исправляем орфографическую ошибку, нам необходимо выпустить новую версию с дублированием всех сущностей: макета, каталогов и т. д.

Для реализации техники версионирования в базе данных , мы решили скопировать всю схему в Postgres со всеми сущностями для новой версии. Мы не обнаружили никаких недостатков этого подхода, за исключением того, что он замедляет работу пользовательского интерфейса инструментов, которые сканируют все схемы для их отображения и управления ими. Несмотря на то, что ограничений на количество схем почти нет, это не так важно, потому что жизненный цикл схемы для каждой версии не длится очень долго и ограничивается продолжительностью разработки версии и ее тестирования. После того, как новая версия инфомодели готова и протестирована, мы ее выпускаем. Но что означает освобождение?

Что происходит на этапе выпуска

Мы выпускаем новую версию инфомодели, когда уверены, что применили все изменения и готовы запустить ее в производство.

Для запуска новой версии в производство мы запускаем сервисы валидаторов и серию E2E-тестов. Они проверяют выпуск новой версии метаданных, чтобы гарантировать, что она не будет семантически разрушать пользовательский опыт. Следующий шаг — сгенерировать манифесты из текущего состояния базы данных и сбросить их в хранилище статических файлов. Вот и все.

Когда клиенты требуют выпущенную версию макета, службы внешнего интерфейса обращаются к этому хранилищу манифестов и подготавливают их для обработки запросов клиентов. Эти файлы распространяются nginx с разным уровнем кэширования, например, etags. Каждый новый выпуск создает дамп новой версии и никогда не затрагивает старые версии, поскольку мы использовали только добавление версий.

Однако, когда мы хотим протестировать конкретную версию в staging, мы не делаем всех этих шагов. Вместо этого манифесты генерируются по запросу. Манифесты могут быть очень большими, поскольку некоторые из них содержат иерархические зависимости данных и могут ухудшить работу пользователя. Чтобы решить эту проблему, вопросы производительности и памяти в продакшене, мы разделяем такие манифесты на иерархические разделы. Это повышает скорость генератора по требованию и увеличивает количество попаданий в кэш для манифестов в рабочей среде.

Распространение релиза

Формат файлов json, которые сохраняются для чтения и интерпретации внешним интерфейсом, будет обсуждаться в части внешнего интерфейса. На данный момент стоит отметить, что они никогда не удаляются, а также разбиваются на отдельные части в целях оптимизации для внешних служб. Хранилище обеспечивает легкий доступ ко всем версиям инфомодели, которые когда-либо были выпущены, и мы не беспокоимся о том, что кто-то запросит абсолютные или старые версии, они всегда будут доступны. После выполненного релиза мы архивируем схему базы данных этой версии.

Внешние службы — это базы данных только для чтения со встроенным пользовательским интерпретатором для их упрощенного DSL. Существует три службы: служба компоновки, служба механизма правил и служба создания URL-адресов. Однако из-за архитектуры всей системы они имеют много общих деталей реализации и свойств. Давайте сначала посмотрим на диаграмму компонентов для служб внешнего интерфейса:

Рисунок 12. Диаграмма компонентов для служб внешнего интерфейса

Может показаться, что службы действуют как прокси перед хранилищем. Но это не так, потому что файлы метаданных, находящиеся в хранилище, сами по себе не имеют смысла. Во-первых, вы должны «скомпилировать» файлы метаданных, чтобы выполнять к ним запросы. Кроме того, у сервисов нет нагрузки на запись, и они действительно услуги без гражданства . Это свойство дает нам Неограниченное горизонтальное масштабирование ( по крайней мере, пока сети кластеров k8s не лопнут).

Рисунок 13. Диаграмма потока запросов

Диаграмма потока запросов показывает нам, что службы внешнего интерфейса делают внешние исходящие запросы только в том случае, если запрошенный макет отсутствует в кеше. Это единственный случай, когда нам нужны внешние запросы, в противном случае сервис отвечает на запрос из внутреннего кеша в памяти. Исходящие запросы происходят редко. Они происходят при выпуске новой основной ветки инфомодели, запуске новых A/B-тестов или развертывании сервисов. Но сначала мы должны поговорить о кэшировании.

Освобождение кэша

Сколько макетов экземпляр может хранить в памяти одновременно? В реальном мире ответ — это зависит. Наиболее важными причинами являются количество зависимостей между атрибутами, которые превращаются в объемы ОЗУ, занимаемые службой. Самая глубокая категория Авито с большим количеством атрибутов и взаимозависимостей между ними — категория авто. Только посмотрите на количество зависимостей только для производителя автомобилей Acura:

Рисунок 14. Количество узлов и зависимостей между атрибутами

На данный момент ясно, что мы не можем позволить себе хранить все макеты в памяти. Мы не можем этого сделать из-за огромного размера и постоянно меняющегося количества макетов из-за A/B-тестов и пошаговой разработки системы. Мы должны использовать ограничение, которое представляет собой количество макетов, которые мы можем хранить в памяти одновременно:

Рисунок 15. Использование слота кэш-памяти. Зеленая линия — это выпуск новой версии сервиса

. Однако в нашем случае мы не можем просто использовать стратегию LRU или LFU для вытеснения раскладок. Причина в непропорциональном использовании разных макетов. Например, верстка для проверки подачи новой рекламы встречается на пару раз реже, чем верстка показа атрибутов на странице с рекламой:

Чтобы решить эту проблему, мы выбрали кэш ARC. Кэш Arc отслеживает частоту и давность использования определенного макета. Это помогает не вытеснять макеты, которые получают относительно мало запросов в секунду, но также очень важны. Примером такого макета является отправка нового объявления, которое имеет небольшое количество запросов, но очень важно иметь его в кеше из-за важности не пропустить отправку формы пользователем.

Прогрев кеша

Всякий раз, когда мы развертываем группу экземпляров интерфейсных служб в рабочей среде, они запускаются с пустым кешем. Разогрев на реальных запросах пользователей — плохой опыт для наших потребителей, потому что это может закончиться неудачным запросом на отправку нового объявления. Поэтому мы придумали стратегию разогрева.

Каждая служба знает, что находится в ее кеше в памяти. Таким образом, экземпляр выгружает список макетов в памяти в кластер Redis.

Рисунок 17. Процесс прогрева кэша в памяти

Процесс развертывания выглядит следующим образом:

• Мы используем стратегию скользящего обновления, которая позволяет нам распределять нагрузку, когда мы чрезмерно загружаем спецификации макетов.
• Экземпляр переходит к кластерам Redis и получает список используемых в данный момент макетов.