Кейс 500Px: Создание Системы Аналитики Для Крупного Фотохостинга С Нуля

Бывший аналитик фотохостинга 500px Самсон Ху написал заметка о том, как он с нуля разрабатывал систему аналитики для сервиса, с какими проблемами столкнулся и какие методы и инструменты использовал для их решения.

В разделе Growth Hacks — перевод заметки.

Я не колебался, когда решил присоединиться к проекту 500 пикселей на посту руководителя аналитического отдела.

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

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

Это место, где:

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

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

• Команды самостоятельно используют правильные инструменты для ответа на свои вопросы о данных.

• Мы можем предсказать будущее, просматривая данные и обнаруживая прогностические индикаторы.

Да и помощи ждать будет не от кого.

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

Но трудности меня ничуть не пугают — я сразу взялся за проект. Прошел год с тех пор, как я участвовал в проекте.

Мы добились больших успехов в восстановлении нашей инфраструктуры и совершенствовании процесса отчетности.

Основным источником истины для нас на данный момент является Хранилище данных Redshift .

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

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

Мы еще не закончили работу в этом направлении.

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

Я хочу написать о двух разных типах данных — технических данных и бизнес-данных.

Сегодня много контента по созданию информационной инфраструктуры.

Кроме того, по аналитике стартапов написаны сотни статей, цель которых — определить, какие метрики важны.

Но о внедрении и управлении пишет лишь незначительное меньшинство авторов — они рассматривают аналитику как бизнес-функцию.

Я изложу свое видение этой проблемы.

Немного общей информации

Компания

Наша платформа включает в себя веб-сайт для настольных компьютеров и мобильных устройств, мобильные приложения для Android и iOS, а также сторонние приложения, такие как Flipboard. Нас поддерживают первоклассные инвесторы, в том числе Андреессен Горовиц И Венчурный капитал .

У нас есть два основных источника дохода:

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

• Фотомагазин, где мы берем процент с каждой продажи.

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

Кроме того, у нас есть высшее руководство.

В целом численность штатных сотрудников достигает 60 человек.

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

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

Четкое понимание того, о чем нам говорят показатели, имеет решающее значение для принятия решений на высшем уровне.

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

Стек технологий

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

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

У нас даже есть данные о покупке подписок и покупках из фотобанка.

Мы регистрируем вызовы API и изменения состояния на стороне сервера.

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

Если вы не знаете, файл журнала состоит из простых текстовых файлов.

Когда мы регистрируем действие, мы просто добавляем запись в виде строки, которая выглядит так: 2015–02–10 10:24:31.32444 23432423 photo_like 423223 123.132.623.123 /get?… Каждая такая строка может содержать временную метку, идентификатор фотографии, идентификатор пользователя, IP-адрес пользователя, действия пользователя и все, что имеет отношение к делу.

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

Мы собираем около 20 ГБ файлов записей в день.

Все эти источники данных, MySQL и журналы, очень полезны для аналитики.

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

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

Путь к лучшей аналитике

Два источника данных

Splunk — это поисковая система по журналам «поверх журналов».

Записи журнала событий могут многое рассказать о поведении пользователей.

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

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

Но файлы журнала событий — это просто текстовые файлы.

Из этих файлов очень сложно получить что-либо ценное; сначала нужно их разобрать.

Здесь на помощь приходит Splunk. Splunk — это инструмент, который позволяет искать и анализировать данные журнала событий.

Например, меня интересуют следующие вопросы:

• Сколько фотографий средний пользователь загружает за один сеанс?
• Сколько пользователей Android использовали нашу платформу за последний месяц?

Две головные боли

Если мне нужна была информация о состояниях, я делал запрос через MySQL. Если я хотел получить данные о поведении пользователей, запрос делался через Splunk. Но если вам нужна информация как о поведении, так и о состоянии, например, скольким пользователям понравилась определенная фотография за последний месяц (Splunk), с разбивкой по типу подписки пользователя (MySQL), тогда вам понадобится какой-то способ сделать это в автономном режиме.

.

-запрос из этих двух источников данных отдельно.

И тогда вам нужно найти способ совместить и то, и другое.

Для таких запросов я использовал Python и библиотеки MySQL и Splunk. Это все еще немного головная боль.

Не хватило времени написать собственный код для организации сбора данных.

Но проблема заключалась не только в этом.

Эти два источника данных было непросто использовать.

В Splunk есть специальный язык запросов, для которого существует несколько онлайн-ресурсов.

А схемы в MySQL были плохо документированы.

Таким образом, ответственность за сбор данных ложится исключительно на аналитика.

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

Панель инструментов лидерства — беги

Мы использовали Splunk для подсчета количества событий (подписок, загрузок и т. д.) по дате и клиенту (веб, iphone, android и т. д.).

Результат этих поисков через Splunk сохранялся в Google Sheet и дублировался на панели управления Exec, передавая параметры скрипту, который запускался каждую ночь:



Информационная доска наших лидеров.

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

Было очевидно, что пришло время что-то менять.

Например, данных не было.

Я был завален сбором данных в течение четырех месяцев, и с таким же успехом я мог бы сменить название своей должности на Data Monkey. Трудно было винить инфраструктуру, тем более, что я был новичком в компании.

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

Лишь немногие могли понять наши метрики.

Информационное табло для руководства было настоящей катастрофой.

Я должен был действовать.

Мне нужно было перестроить инфраструктуру, сохранив при этом текущий процесс отчетности.

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

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

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

Но это было необходимо.

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

Вот почему я люблю стартапы.

Вы можете сделать что-то вроде этого.

С точки зрения инфраструктуры мне нужно было всего две вещи:

• База данных, объединяющая журнал событий и MySQL, к которой легко обращаться.

• Простой интерфейс к этой базе данных.

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

К счастью, нам не пришлось изобретать велосипед. Есть продукты, которые решают именно эти две проблемы.

В следующих двух разделах статьи я расскажу о реализации базы данных Redshift и проекте Periscope. А затем я расскажу о переформатировании отчетов по метрикам с помощью Periscope и Google Sheets.

Новая инфраструктура.

Часть 1 — Красное смещение

Если вы уже знакомы с этой концепцией, вы можете сразу перейти к следующей.

Инструкции по размерному моделированию

Это база данных SQL, специализированная для бизнес-аналитики, отличающаяся от производственной базы данных для приложений.

Оно должно быть простым для понимания и создания запросов.

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

Данные поступают из источника (MySQL и журналы) и преобразуются в эти два типа таблиц посредством процесса извлечения-преобразования-загрузки (ETL).

Схема ETL и многомерного хранилища данных

• Таблица фактов записывает измерения во время процесса.

• Таблица размеров записывает информацию о конкретном товаре.

Имена и значения столбцов должны быть читаемыми.

Например:

• Таблица фактов «Нравится» имеет следующие столбцы: дата-время, user_id, photo_id, client.
• «Произвольная» таблица пользователей содержит столбцы: user_id, user_name, имя, фамилия, .

  , тип_подписки, .

  , продавец, .

  , has_android_application, .

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

Параметр тип_подписки не содержится в таблице фактов «Нравится».

А ID пользователя содержится.

Тогда нам нужно будет объединить таблицу фактов для «лайков» с таблицей «размеров» для ID пользователя , а затем сгруппируйте данные по user_subscription_type .

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

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

ЭТЛ

Таблицы часто денормализованы и их многочастность скрыта.

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

Но в хранилище данных пользовательская таблица должна просто содержать столбец «да/нет».

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

Отсюда и название процесса E-T-L (Извлечение-Преобразование-Загрузка).

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

Создать схему

Учитывая мои прошлые запросы, я получил ряд требований к таблице:

• Таблицы фактов : Покупка подписки, покупка в фотобанке, скачивание, регистрация, лайк, добавление в избранное, подписка на пользователей,.

• Таблицы «Размеры» : Пользователи, фотографии.

Но удовлетворяет ли эта схема наши потребности? Эта модель данных содержит журнал событий и данные MySQL в одном месте, и для их объединения не требуется никакой дополнительной работы.

Это легко понять и прочитать.

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

Но иногда наших моделей данных просто недостаточно:

1. Если для нашего вопроса нет правильной таблицы.

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

Амазонка Редшифт

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

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

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

Попробуйте объединить 100-миллионную таблицу с 500-миллионной таблицей в MySQL. Даже Postgres здесь потерпит неудачу.

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

К счастью для нас, есть дешевая, простая в использовании и обслуживании база данных, оптимизированная специально для аналитических запросов, таких как соединения и агрегации: Amazon Redshift на AWS. Базы данных Redshift с двумя терабайтами дискового пространства вполне достаточно для наших нужд, и она стоит чуть больше 4 тысяч долларов в год.

Создание ЭТЛ

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

Получение некоторой информации, необходимой для ETL, требует множества тонкостей и множества взаимоотношений.

Например, основной проблемой в наших показателях является измерение подписок, обновлений и показателей оттока.

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

Но поскольку этот пользователь уже был подписчиком, получилось, что мы посчитали его дважды.

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

MySQL не имеет такого столбца.

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

Единственный столбец, который у нас есть, — «активный».

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

В этой таблице мы оставили графу «присоединились» и удалили данные о ранее активных подписчиках, получив таким образом исправленный счетчик новых подписчиков.

То же самое делаем и для добавления пользователей в столбец «обновлено».

Планы производства просто ужасны для аналитики.

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

Используйте инфраструктуру, например Луиджи или такой инструмент, как информатика .

Они содержат хорошо известные стили и концепции кодирования и широко используются.

Все равно аналитика будет довольно запутанной.

Но по крайней мере это будет сравнимо с известными методами проведения ETL. Если вы проигнорируете мои советы и создадите что-то свое, то никто не сможет понять систему, если вы однажды уйдете из компании.

Для создания каналов ETL я предпочитаю работать в Luigi. Есть много причин для этого:

• Луиджи создан и поддерживается Spotify. Его используют в тысячах стартапов по всему миру.

  У них есть активный список рассылки и растущее сообщество.

• Luigi имеет открытый исходный код и расширяемый.

  Совершенно понятно, как все работает, и расширять количество базовых классов не возбраняется.

• Luigi построен на Python, популярном языке обработки информации.

• Код Луиджи легко читается.

  Основными элементами Luigi являются классы задач, которые формируют основные операции ETL. Они состоят из трех частей.

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

  Луиджи даже сможет визуализировать этот график с помощью функции визуализации, а также предоставить диагностическую информацию о каждом запуске ETL.

• Когда код структурирован таким образом, его гораздо легче читать и поддерживать.

  Здесь есть иерархия и отношения.

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

  Это позволяет мне быстро увидеть структуру кода и выделить интересующие меня части.

• Луиджи идемпотент. Это означает, что если вы запустите его два раза подряд, один за другим, ничего не произойдет. Он просто повторно запустит части кода, если вы уже удалили результат предыдущих задач.

  И это невероятно полезно во время отладки.

  Если запуск прервался в какой-то момент, вам просто нужно исправить этот момент и затем запустить процесс заново.

  Вам не нужно изолировать эту часть кода, методично запуская ее изолированно.

• Луиджи отправляет уведомление по почте с данными о регистрации ошибок и статусе выполнения.

  Вы получите уведомление, если на каком-либо этапе запуска произойдет сбой.

  Вы можете просмотреть трассировку стека ошибок, исправить код и повторно запустить ETL.

Эти шаги включали извлечение данных из MySQL, загрузку данных в S3 и загрузку всех этих данных из S3 в Redshift. В одной конкретной точке запускается экземпляр Elastic Mapreduce для анализа данных журнала событий и преобразования их в данные таблицы фактов, которые сохраняются в S3, а затем загружаются в Redshift. Полный цикл выполнения ETL занимает около четырех часов.

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

Хранилище завершенного сбора данных

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

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

Но через некоторое время все стабилизируется.

Люди перестанут требовать, чтобы что-то изменилось.

Вы привыкнете к тому, с какой частотой инженерный отдел меняет схему производства.

А инженерный отдел установит с вами связь и предупредит, что вносят изменения.

Существует несколько способов проверить точность данных в хранилище данных.

Подробнее об этом будет написано ниже.

В целом управление этим хранилищем данных обойдется вам менее чем в 8000 тысяч долларов в год. И это сопоставимо с традиционными решениями для хранения данных аналогичного масштаба.

Новая инфраструктура.

Часть 2 — Перископ

Я оценил несколько популярных вариантов:

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

  Но мы не могли позволить себе платить за это решение более 30 тысяч долларов в год.

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

  Нелегко вести отчетность и создавать списки.

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

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

Немного о Перископе:

• Periscope — это инструмент аналитики, в котором вы можете писать SQL для создания графиков.

• Periscope легко подключается к Redshift, поскольку оба они представляют собой облачные решения.

• Информационное табло является основным видом документа.

• На этих досках пользователи могут писать SQL для создания графиков и таблиц.

• Его можно использовать коллективно.

  Неограниченное количество сотрудников компании могут войти в свою учетную запись и просматривать доски других сотрудников.

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

• Каждая доска автоматически обновляется каждый час, поэтому вы всегда получаете правильные данные.

• Вы можете настроить доски на отправку себе электронных писем в определенное время.

1. Инструмент основан на SQL, поэтому изучение SQL является обязательным.

   Но поскольку досками так легко делиться, использование Periscope теперь стало социальной деятельностью внутри компании.

   А это, в свою очередь, стало сильной мотивацией к изучению SQL.

2. Несистематический анализ в Periscope выполняется очень быстро.

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

   А если вы сможете быстрее отлаживать, то и ответы на свои вопросы вы получите быстрее.

3. С Periscope легко создавать отчеты.

   Чтобы создать список, просто создайте новую информационную доску, напишите свой SQL и нажмите «Сохранить».

   Затем вы можете поделиться ссылкой на доску или экспортировать таблицу в формате CSV.

4. Перископ — многофункциональный инструмент для создания информационных досок.

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

   А потом каждое утро я рассылал эти доски всем в компании.

5. Инструмент Periscope можно использовать коллективно.

   Любой сотрудник компании может прийти и посмотреть, над чем работают другие.

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

   Те пользователи, которые на каком-либо этапе создания запроса застряли, могут легко обратиться за помощью к другим пользователям.

6. Цена на этот продукт разумная.

   Учитывая, что в нашей компании работает более 60 человек, я был в полном восторге, когда увидел, сколько нам будет стоить месяц.

Теперь поток данных по всей компании движется без моей помощи.

Я освободил много времени, которое раньше тратил на загрузку данных.

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

Поэтому внедрение Redshift и Periscope оказалось очень удачным решением.

Оценка эффективности и отчетность

Определение формата

Старая панель управления в Google Sheets нуждалась в полной переработке с таким большим количеством цифр.

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

Отделу маркетинга не нужна такая подробная информация о маркетинговых показателях.

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

Это была настоящая проблема.

Необходимо было создать новый набор информационных стендов.

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

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

Я начал сверху: сначала разработал доску для менеджеров.

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

Я тесно работал над вице-президентом по продукту и вице-президентом по операциям, настраивая различные способы измерения компании.

Мы что-то меняли, пробовали несколько решений.

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

Это сжатие менялось в течение пяти недель.

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

Рядом с еженедельными показателями были запланированные цифры, которые мы экспортировали из основного документа планирования.

Мы могли сравнить эти цифры и понять, движется ли компания по графику.

Этот дамп данных для менеджеров – важнейшая информационная доска.

Это закладывает основу того, как люди на 500px должны думать о своей работе.

Из этого отрывка появились информационные доски для других команд компании.

В итоге я создал набор досок для всех этих команд:

• Отдел разработки продуктов.

• Отдел сайта.

• Отдел мобильных приложений.

• Отдел маркетинга.

• Отдел продаж.

Каждая доска включала показатели исполнительного руководства.

• Решение Об Аутсорсинге Услуг Информационных Технологий

  19 Oct, 24

• Советы По Воспроизведению Dvd-Видео На Планшете

  19 Oct, 24

• Повысьте Прибыльность Вашего Бизнеса С Помощью Bandwidth Manager

  19 Oct, 24

• Конические Сечения

  19 Oct, 24

• Насколько Маленьким Может Быть Ядро ​​Linux?

  19 Oct, 24

• У Тебя Есть Борода?

  19 Oct, 24

• Исповедь Фулстака: Профессия, Религия, Мечты

  19 Oct, 24

• Иллюзия

  19 Oct, 24

• Накрутка Показов На Поиске Y.direct: Почему Вы Платите В 1,5 Раза Больше За Клик

  19 Oct, 24

• Пила «Лазерным Прицелом»

  19 Oct, 24