Только примерно 20% больных реальной депрессией ищут медицинскую или психологическую помощь, причем большинство из них обращаются к участковым терапевтам и неврологам. Те, в свою очередь, не всегда готовы к правильной диагностике, вследствие чего лишь около 30% депрессий (из числа 20% обратившихся) диагностируются своевременно и из них лишь 25% пациентов, в среднем, получает необходимую антидепрессивную терапию, лекарственную или иную. Трагичность (почему бы и не да) этих цифр тем более очевидна, если учесть тот факт, что в 60-70% случаев правильное научное лечение приносит пациентам быстрый желаемый эффект.

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

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

Весь прикол КТ в том, например, что известен эксперимент, в котором однажды один ученый впрыскивал в кровь испытуемым добровольцам в большой дозе адреналин, не говоря им, что это он. Люди становились психосоматически и объективно, по показаниям приборов, возбужденными, но 2/3 из них заявляли, что не испытывают никаких эмоций, а 1/3 говорила, что испытывала что-то похожее на эмоцию. Исследования других ученых показали, что одного физиологического возбуждения (или другого ощущения) недостаточно для возникновения эмоции, необходимо, чтобы человек распознал это реальное возбуждение, осознал, оценил и обозначил его словесно, мысленно, как это ему свойственно. Например, учащенное после подъема по лестнице на 10-й этаж сердцебиение ипохондричный пессимист назовет страшным приступом тахикардии, а спортивный оптимист - кайфовой тренировкой кровообращения. Изменения в организме у обоих одинаковые, но через минуту или час у первого настроение и здоровье ухудшится (приболел), а у второго - улучшится (потренил), причем не только субъективно, но и объективно, по показаниям самых современных высокоточных приборов. Получается, что отрицательные или положительные эмоции - следствие привычного (чаще наученного или наследственного) оценивания и убеждения в том, что они вызваны вредной или полезной данной конкретной причиной. Приблизить субъективное к объективному ради здоровья и успеха первоклассно помогает как раз КТ.

Начало практики когнитивной самокоррекции включает более подробное информирование о её философии (коротко повторим - эмоциональные проблемы вызывают не сами события, а их оценка) и о последовательных этапах восприятия события человеком в виде:

Ао --> Ас --> В --> C

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

Описательные мысли, как уже отмечалось, соединены с оценочными установками связями разной степени жесткости. Начиная от абсолютно исключающих какие-либо варианты, протекающих по типу рефлекса, при которых отношение к событию уже предопределено и тогда можно говорить о наличии у вас иррациональной установки (ИУ), заканчивая многовариантными, когда при принятии решения о действии осуществляется анализ альтернативных вариантов, хотя он может протекать неосознанно, и тогда можно говорить о наличии рациональной установки. Цель КТ перевод в проблемных ситуациях с иррациональных, депрессивных и стрессовых установок на максимально рациональные и приятные.

Работа в КТ всегда строится с учетом схемы А, В, С. Сначала:

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

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

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

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

а) самонаблюдение за мимическими проявлениями при вашем воспоминании об эмоции и предоставление письменной обратной связи вами самими,

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

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

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

a) вспоминательная фокусировка на тех мыслях, которые приходили Вам на ум в момент столкновения со стрессовым событием,

b) высказывание вами самими гипотетических предположений типа У меня в такой стрессовой ситуации возникли бы следующие мысли,

c) вопросы с проекцией в будущее время, например: Предположим, что произойдет самое худшее в ситуации стресса, что же это будет? и др.

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

Самая распространенная группа ИУ, создающих всеразличные проблемы - это катастрофические установки (отмечайте тут возможные ваши):

Я настолько расстроен(а) и несчастлив(а), что не могу это выдержать.

Мое будущее безнадежно, и ничто не может измениться к лучшему.

Я чувствую, что как личность, я полный(ая) неудачник(ца).

Я полностью не удовлетворен(а) жизнью и мне все надоело.

Я постоянно испытываю чувство вины.

Я чувствую себя уже наказанным(ой).

Я себя ненавижу.

Ко мне приходят мысли покончить с собой, но я не буду их осуществлять.

Я виню себя во всем плохом, что происходит.

Раньше я мог(ла) плакать, а сейчас не могу, даже если мне хочется.

Теперь я постоянно чувствую, что раздражен(а).

Я полностью утратил(а) интерес к другим людям.

Я с трудом заставляю себя сделать что-либо.

Я полностью утратил(а) сексуальный интерес.

Мой аппетит теперь значительно хуже.

Я очень обеспокоен(а) своим физическим состоянием и мне трудно думать о другом.

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

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

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

Я расстроен(а).

Я все время расстроен(а) и не могу от этого отключиться.

Я чувствую, что озадачен(а) будущим.

Я чувствую, что меня ничего не ждет в будущем.

Я чувствую, что пережил(а) больше неудач, чем другие люди.

Когда я оглядываюсь на мою жизнь, я вижу в ней очень много неудач.

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

Я больше не получаю удовлетворения ни от чего.

Достаточно часто я чувствую себя виноватым(ой).

Большую часть времени я чувствую себя виноватым(ой).

Я чувствую, что могу быть наказан(а).

Я ожидаю, что могу быть наказан(а).

Я разочаровался(ась) в себе.

Я себе противен(на).

Я критикую себя за ошибки и слабости.

Я все время обвиняю себя за свои проступки.

Сейчас я плачу чаще, чем раньше.

Теперь я все время плачу.

Я более легко раздражаюсь, чем раньше.

Я меньше интересуюсь другими людьми, чем раньше.

Я почти потерял(а) интерес к другим людям.

Я чаще, чем раньше, откладываю принятие решения.

Я больше не могу принимать решения.

Я знаю, что выгляжу безобразно.

Мне необходимо сделать дополнительное усилие, чтобы начать делать что-нибудь.

Я совсем не могу выполнить никакую работу.

Сейчас я сплю хуже, чем раньше.

Я просыпаюсь на 1-2 часа раньше обычного и мне трудно заснуть опять.

Теперь я устаю быстрее, чем раньше.

Я устаю почти от всего, что я делаю.

Я не могу ничего делать из-за усталости.

Мой аппетит стал хуже, чем раньше.

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

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

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

Результаты: 0-1 нормально, до 5 плюсов требуется помощь психолога, более 5 нужно к врачу-психотерапевту или психиатру.

Цель диагностического этапа реализована, когда в области стресса или депрессии выявлены такие или им подобные ИУ, показан характер связи между ними и отношениями в семье, на работе и т.д. Уточнение рациональных установок и целей также необходимо, поскольку они составляют ту позитивную часть отношения, которая в последующем может быть расширена. Что мы и сделаем, насколько это возможно, чуть дальше. Хотя в приложения есть хорошие для здесь и сейчас), например - Mindspa: психологическая помощь в любой момент или Психология самооценки: 6 практик. Личностный рост с BestHelp Психологическая помощь онлайн.

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

Чтобы успешно уменьшить депрессию и любые неприятные мысли, обязательно нужно понять и принять базисное и наиглавнейшее положение когнитивной самокоррекции о зависимости эмоций от мышления: Если мы хотим изменять чувства, надо изменять вызвавшие их идеи. КТ уже началась сразу после осознания и принятия вами самими (и только так) некоторых ваших суждений и идей о проблемах и желаниях с постепенным переводом некоторых из них на позиции улучшения ИУ.

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

Максимально быстрое осознание способов неадекватной обработки информации и замена их правильными - таковы главные общие задачи когнитивной самокоррекции. Она наиболее показана людям с 14-16 лет со способностью к самонаблюдению и анализу своих мыслей. Т.е. сознательным товарищам.

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

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

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

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

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

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

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

Вы можете сказать - хватит указывать, кто виноват, лучше опишите что, когда и как делать!. Чрезвычайно согласен, настолько, насколько это только возможно.

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

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

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

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

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

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

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

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

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

Медийная реклама Ozon представлена на разных площадках: Facebook, Google, MyTarget, TikTok и другие. Для эффективной работы любой рекламной кампании необходима оперативная аналитика. В данной статье речь пойдет о моём опыте сбора рекламных данных с площадки TikTok без посредников и лишних заморочек.

Задача на сбор статистики: вводные

У команды медийной рекламы Ozon есть бизнес-аккаунт TikTok, в котором они управляют всей рекламой на этой площадке. Они долго терпели, сами собирали данные из рекламных кабинетов, но всё-таки настало время, когда терпеть уже больше было нельзя. Так у меня появилась задача на автоматизацию сбора статистики из TikTok.

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

Итак, весь процесс от "нам нужны данные по расходам из TikTok" до "у нас есть данные по расходам из TikTok" разделился для нас на следующие этапы:

1. регистрация аккаунта разработчика,

2. создание приложения,

3. авторизация бизнес-аккаунта в приложении,

4. запрос, получение, обработка и загрузка данных.

Рассмотрим каждый из этапов подробнее.

Регистрация разработчика

Мы зарегестрировали аккаунт разработчика на нашего бизнес-менеджера. Перешли на портал TikTok Marketing API, нажали на "My Apps", далее кликнули на "Become a Developer", и началась череда заполнения форм.

TikTok не Facebook, у нас ничего ни разу не отклонял, но всё равно мы были очень внимательны при заполнении полей и не добавляли то, что нам не нужно прямо сейчас. Например, в поле "What services do you provide?" добавили только "Reporting".

Последним пунктом был "Create App". Процесс создания аккаунта разработчика и приложения в первый раз происходит вместе.

Создание приложения

Заполняем имя и описание приложение, callback-address. Далее нужно выбрать разрешения, которые приложение будет запрашивать у авторизирующегося в нем аккаунта. Так же, как и при заполнении полей для аккаунта разработчика, выбрали только пункт "Reporting". Указали ID рекламного аккаунта. После этого отправили приложение на проверку.

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

К сожалению, у меня нет для вас советов на тот случай, если ваше приложение не одобрили. Главное, о чём нужно помнить это правильно заполнять все обязательные поля и запрашивать разрешения только на то, что действительно необходимо: ни больше, ни меньше.

Авторизация бизнес-аккаунта в приложении

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

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

1. Зашли в приложение и указали Callback Address https://www.ozon.ru.

2. Скопировали Authorized URL, перешли по нему, авторизовались под аккаунтом бизнес-менеджера.

3. Согласились на предоставление разрешений для приложения, нажали "Confirm".

4. Далее нас перекинуло на сайт Ozon, но с дополнительными аргументами в url. Получилось наподобие такого https://www.ozon.ru/?auth_code=XXXXXXXXXXX.

5. Скопировали значение auth_code, в приложении скопировали secret и app_id и отправили запрос к TikTok на получение long-term Access Token.

curl -H "Content-Type:application/json" -X POST \-d '{    "secret": "SECRET",     "app_id": "APP_ID",     "auth_code": "AUTH_CODE"}' \https://ads.tiktok.com/open_api/v1.2/oauth2/access_token

Получили ответ такого вида:

{    "message": "OK",     "code": 0,     "data": {        "access_token": "XXXXXXXXXXXXXXXXXXXX",         "scope": [4],         "advertiser_ids": [            1111111111111111111,             2222222222222222222]    },     "request_id": "XXXXXXXXXXXXXXX"}

Важно было успеть отправить запрос на получение long-term Access Token как можно быстрее, после редиректа на сайт Ozon. Связано это с временем жизни auth_code 10 минут.

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

Так же при запросах нам понадобиться список advertiser_ids, но его не обязательно сахранять прямо сейчас список ID аккаунтов всегда можно посмотреть в аккаунте бизнес-менеджера.

Всё, мы готовы писать запросы!

Получение статистики

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

Итак, у нас есть всё необходимое для получения данных, а именно:

• access_token,

• список advertiser_ids.

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

Значение media source всегда неизменно, так как источник один TikTok. По остальным параметрам можно запросить данные из API TikTok.

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

В новом методе получения данных добавили фильтр по типу размещения рекламы: AUCTION и RESERVATION. Ozon использует только AUCTION в своей стратегии ведения кампаний.

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

METRICS = [    "campaign_name", # название кампании    "adgroup_name", # название группы объявлений    "ad_name", # название объявления    "spend", # потраченные деньги (валюта задаётся в рекламном кабинете)    "impressions", # просмотры    "clicks", # клики    "reach", # количество уникальных пользователей, смотревших рекламу    "video_views_p25", # количество просмотров 25% видео    "video_views_p50", # количество просмотров 50% видео    "video_views_p75", # количество просмотров 75% видео    "video_views_p100", # количество просмотров 100% видео    "frequency" # среднее количество просмотра рекламы каждым пользователем]

В документации TikTok для каждого метода API описан пример на языках Java, Python, PHP и также curl-запрос. Я использовала пример на Python с небольшими изменениями.

В примерах из документации TikTok используются две дополнительные библиотеки:

pip install requestspip install six

Библиотека requests необходима для удобной отправки get-запросов. Библиотека six используется для генерации url-адреса запроса.

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

pip install pandaspip install sqlalchemy

В нашей компании для хранения данных используются SQL-подобные хранилища, поэтому я использую pandas для преобразования данных в DataFrame и sqlalchemy для записи DataFrame в базу.

Я использовала функции из примера в документации TikTok для генерации url и отправки запроса.

# генерирует url на основе словаря args с аргументами запросаdef build_url(args: dict) -> str:    query_string = urlencode({k: v if isinstance(v, string_types) else json.dumps(v) for k, v in args.items()})    scheme = "https"    netloc = "ads.tiktok.com"    path = "/open_api/v1.1/reports/integrated/get/"    return urlunparse((scheme, netloc, path, "", query_string, ""))# отправляет запрос к TikTok Marketing API,# возвращает результат в виде преобразованного json в словарьdef get(args: dict, access_token: str) -> dict:    url = build_url(args)    headers = {        "Access-Token": access_token,    }    rsp = requests.get(url, headers=headers)    return rsp.json()

На вход функции get нужно передать список аргументов и access token. Список аргументов под наши цели выглядит следующим образом:

args = {    "metrics": METRICS, # список метрик, описанный выше    "data_level": "AUCTION_AD", # тип рекламы    "start_date": 'YYYY-MM-DD', # начальный день запроса    "end_date": 'YYYY-MM-DD', # конечный день запроса    "page_size": 1000, # размер страницы - количество объектов, которое возвращается за один запрос     "page": 1, # порядковый номер страницы (если данные не поместились в один запрос, аргумент инкрементируется)    "advertiser_id": advertiser_id, # один из ID из advertiser_ids, который мы получили при генерации access token    "report_type": "BASIC", # тип отчета    "dimensions": ["ad_id", "stat_time_day"] # аргументы группировки, вплоть до объявления и за целый день} 

Подробнее про page_size: ответ на запрос может содержать большое количество информации и загружать всё это за один раз не эффективно. Поэтому у TikTok есть ограничение на максимальное количество объектов в ответе 1000. Чтобы получить следующую порцию данных, нужно отправить запрос с теми же входными аргументами на следующую страницу. Подробнее о постраничных запросах ниже.

В ответ на запуск функции get получаем словарь подобного вида.

{       # маркер успешности ответа    "message": "OK",    "code": 0,    "data": {        # информация о странице данных        "page_info": {            # общее количество объектов            "total_number": 3000,            # текущая страница            "page": 1,            # количество объектов на одной странице ответа            "page_size": 1000,            # общее количество страниц            "total_page": 3        },        # массив объектов        "list": [            # первый объект            {                # метрики                "metrics": {                    "video_views_p25": "0",                    "video_views_p100": "0",                    "adgroup_name": "adgroup_name",                    "reach": "0",                    "spend": "0.0",                    "frequency": "0.0",                    "video_views_p75": "0",                    "video_views_p50": "0",                    "ad_name": "ad_name",                    "campaign_name": "campaign_name",                    "impressions": "0",                    "clicks": "0"                },                # измерения (по каким параметрам группируем результаты)                "dimensions": {                    "stat_time_day": "YYYY-MM-DD HH: mm: ss",                    "ad_id": 111111111111111                }            },...        ]    },    # id ответа    "request_id": "11111111111111111111111"}

Как я описывала выше, если в ответе получается более 1000 объектов, ответ будет разбит на несколько страниц. В данном случае поле total_page говорит о том, что для получения полного набора данных по указанным параметрам, нужны будут три страницы. Следовательно, запускаем и коллекционируем ответы пока не выгрузим все страницы.

page = 1 # сначала всегда получаем данные по первой страницеresult_dict = {} # словарь, в который будем записывать ответыresult = get(args, access_token) # первый запросresult_dict[advertiser_id] = result['data']['list'] # сохраняем ответ на запрос к первой странице# пока текущая полученная страница page меньше # чем общее количество страниц в последнем ответе resultwhile page < result['data']['page_info']['total_page']:    # увеличиваем значение страницы на 1    page += 1    # обновляем значение текущей страницы в словаре аргументов запроса    args['page'] = page    # запрашиваем ответ по текущей странице page    result = get(args, access_token)    # накапливаем ответ    result_dict[advertiser_id] += result['data']['list']

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

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

# результирующий DataFrame, который будем записывать в базуdata_df = pd.DataFrame()# для каждого рекламного аккаунта выполнить преобразованиеfor adv_id in advertiser_ids:    # получаем накопленные разультаты для аккаунта из словаря    adv_input_list = result_dict[adv_id]    # временный список    adv_result_list = []    # для каждого объекта    for adv_input_row in adv_input_list:        # берём словарь метрик        metrics = adv_input_row['metrics']        # насыщаем этот словарь словарём измерений        metrics.update(adv_input_row['dimensions'])        # добавляем полученный объект во временный список        adv_result_list.append(metrics)    # преобразуем временный словарь в DataFrame     result_df = pd.DataFrame(adv_result_list)    # добавляем колонку со значением id аккаунта    result_df['account'] = adv_id    # добавляем получившийся DataFrame в результирующий    data_df = data_df.append(        result_df,         ignore_index=True    )## здесь пропущены некоторые манипуляции # по преобразованию строк в числа## запись данных из результирующего DataFrame в базуdata_df.to_sql(    schema=schema,     name=table,     con=connection,    if_exists = 'append',    index = False)

TikTok утверждает, что исторические данные по статистике не меняеются, а если и меняются, то это должна быть экстроординарная ситуации, наподобие аварии в ЦОД. Но на основе опыта получения данных от Facebook, я решила что всё равно буду перезаписывать семь последних дней (цифра семь появилась эмпирически).

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

# импорт библиотекimport jsonfrom datetime import datetimefrom datetime import timedeltaimport requestsfrom six import string_typesfrom six.moves.urllib.parse import urlencodefrom six.moves.urllib.parse import urlunparseimport pandas as pdimport sqlalchemy# генерирует url на основе словаря args с аргументами запросаdef build_url(args: dict) -> str:    query_string = urlencode({k: v if isinstance(v, string_types) else json.dumps(v) for k, v in args.items()})    scheme = "https"    netloc = "ads.tiktok.com"    path = "/open_api/v1.1/reports/integrated/get/"    return urlunparse((scheme, netloc, path, "", query_string, ""))# отправляет запрос к TikTok Marketing API,# возвращает результат в виде преобразованного json в словарьdef get(args: dict, access_token: str) -> dict:    url = build_url(args)    headers = {        "Access-Token": access_token,    }    rsp = requests.get(url, headers=headers)    return rsp.json()# обновляет данные в базе за последние семь дней# (или, если указаны start_date и end_date, для периода [start_date, end_date])def update_tiktik_data(    # словарь с доступами к API TikTok    tiktok_conn: dict,    # словарь с доступами к базе данных    db_conn: dict,    # список id рекламных кабинетов    advertiser_ids: list,    # необязательное поле: начало периода    start_date:datetime=None,    # необязательное поле: окончание периода    end_date:datetime=None):    access_token = tiktok_conn['password']    start_date = datetime.now() - timedelta(7) if start_date is None else start_date    end_date = datetime.now() - timedelta(1) if end_date is None else end_date    START_DATE = datetime.strftime(start_date, '%Y-%m-%d')    END_DATE = datetime.strftime(end_date, '%Y-%m-%d')    SCHEMA = "schema"    TABLE = "table"    PAGE_SIZE = 1000    METRICS = [        "campaign_name", # название кампании        "adgroup_name", # название группы объявлений        "ad_name", # название объявления        "spend", # потраченные деньги (валюта задаётся в рекламном кабинете)        "impressions", # просмотры        "clicks", # клики        "reach", # количество уникальных пользователей, смотревших рекламу        "video_views_p25", # количество просмотров 25% видео        "video_views_p50", # количество просмотров 50% видео        "video_views_p75", # количество просмотров 75% видео        "video_views_p100", # количество просмотров 100% видео        "frequency" # среднее количество просмотра рекламы каждым пользователем    ]    result_dict = {} # словарь, в который будем записывать ответы    for advertiser_id in advertiser_ids:        page = 1 # сначала всегда получаем данные по первой странице        args = {            "metrics": METRICS, # список метрик, описанный выше            "data_level": "AUCTION_AD", # тип рекламы            "start_date": START_DATE, # начальный день запроса            "end_date": END_DATE, # конечный день запроса            "page_size": PAGE_SIZE, # размер страницы - количество объектов, которое возвращается за один запрос             "page": 1, # порядковый номер страницы (если данные не поместились в один запрос, аргумент инкрементируется)            "advertiser_id": advertiser_id, # один из ID из advertiser_ids, который мы получили при генерации access token            "report_type": "BASIC", # тип отчета            "dimensions": ["ad_id", "stat_time_day"] # аргументы группировки, вплоть до объявления и за целый день        }        result = get(args, access_token) # первый запрос        result_dict[advertiser_id] = result['data']['list'] # сохраняем ответ на запрос к первой странице        # пока текущая полученная страница page меньше,         # чем общее количество страниц в последнем ответе result        while page < result['data']['page_info']['total_page']:            # увеличиваем значение страницы на 1            page += 1            # обновляем значение текущей страницы в словаре аргументов запроса            args['page'] = page            # запрашиваем ответ по текущей странице page            result = get(args, access_token)            # накапливаем ответ            result_dict[advertiser_id] += result['data']['list']    # результирующий DataFrame, который будем записывать в базу    data_df = pd.DataFrame()    # для каждого рекламного аккаунта выполнить преобразование    for adv_id in advertiser_ids:        # получаем накопленные разультаты для аккаунта из словаря        adv_input_list = result_dict[adv_id]        # временный список        adv_result_list = []        # для каждого объекта        for adv_input_row in adv_input_list:            # берем словарь метрик            metrics = adv_input_row['metrics']            # насыщаем этот словарь словарём измерений            metrics.update(adv_input_row['dimensions'])            # добавляем полученный объект во временный список            adv_result_list.append(metrics)        # преобразуем временный словарь в DataFrame         result_df = pd.DataFrame(adv_result_list)        # добавляем колонку со значением id аккаунта        result_df['account'] = adv_id        # добавляем получившийся DataFrame в результирующий        data_df = data_df.append(            result_df,             ignore_index=True        )    #    # здесь пропущены некоторые манипуляции     # по преобразованию строк в числа    #        # создание подключения к базе    connection = sqlalchemy.create_engine(        '{db_type}://{user}:{pswd}@{host}:{port}/{path}'.format(            db_type=db_conn['db_type'],             user=db_conn['user'],             pswd=db_conn['password'],            host=db_conn['host'],            port=db_conn['port'],            path=db_conn['path']         )    )    # удаление последних семи дней из базы    with connection.connect() as conn:        conn.execute(f"""delete from {SCHEMA}.{TABLE}         where date >= '{START_DATE}' and date <= '{END_DATE}'""")    # запись данных из результирующего DataFrame в базу    data_df.to_sql(        schema=SCHEMA,         name=TABLE,         con=connection,        if_exists = 'append',        index = False    )

Миссия выполнена!

Подведем итоги

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

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

Конечно, сравнивать Facebook и TikTok не очень правильно: второй ещё относительно молод и ему еще только предстоит быть обвешанным хитрыми условиями, запретами и всеми возможными сложностями. Но сейчас всего этого пока нет, так что пользоваться TikTok Marketing API крайне удобно. Надеюсь, моя статья вам немного в этом поможет.

Полезные ссылки

• TikTok Marketing API: официальная документация;

• Пример запроса статистики с официальной документации TikTok;

• Библиотека request: официальная документация;

• Библиотека six: официальная документация;

• Библиотека pandas: официальная документация;

• Библиотека sqlalchemy: официальная документация.

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

Каким образом две мобильные ОС пережили эпоху глобального вымирания ознаменованного восхождением Android OS? Как так случилось, что платформы предназначенные для управления смартфонами оказались в телевизорах? Зачем корпорации LG и Samsung вдохнули вторую жизнь в угасающие Tizen OS и webOS? Какие перспективы у названных ОС совершить реванш на рынке портативных гаджетов и причем тут загадочная корейская душа? Об этом всем мы и поговорим далее в статье.

Коллеги по несчастью

Свой победоносный путь операционная система от Google - Android OS, начала в 2008 году. В это же самое время готовился к выходу в мир и первый смартфон под управлением webOS. К этому времени также мир увидела и iOS. Все эти молодые и перспективные ОС должны была вступит в бой за перераздел доли рынка дряхлеющей Symbian. С высоты сегодняшних дней реальность шансов на успех webOS многим может показаться весьма утопической, однако в то время это было далеко не так однозначно. Хотя webOS и был наиболее схож с Android OS, как в архитектуре ядра базирующемся в обоих случаях на Linux, так и в принципах проводимой политики максимальной открытости платформ, к 2009 году количество девайсов с предустановленным Android OS все еще было откровенно говоря мизерным. В то же время ОС на основе Symbian хотя и являлась монополистом на рыке мобильных ОС, но даже ее новоиспеченный владелец и главный клиент Nokia осознавала, что ОС морально устарела и замена платформы это лишь дело времени. Собственно доказательством последнего и стал активный передел рынка мобильных ОС, появлением новых и утратой позиций существующими ОС. Всего за два года детище Apple - iPhone под управлением iOS, отхватила впечатляющие 15% рынка мобильных девайсов.

Хотя Tizen OS и не создавалась с нуля, но по многим параметрам это была действительно новая ОС. Возможно и не такая плохая и явно обладала шансами на жизнь, однако появилась она слишком поздно. Дело в том, что в Samsung озадачились разработкой собственной ОС в общем вовремя и с 2008 года успели выпустить более 20 моделей смартфонов под управлением собственной системы SHP ( Samsung Handset Platform ). Пришедшая на смену SHP операционная система Bada стала ее эволюционным развитием. Увидевшая мир аж в 2012 году Tizen OS для Samsung должна была стать уже скорее революционным развитием собственной платформы. Объединив усилия трех проектов LiMo, MeeGo, Bada новый программный продукт должен был вывести продажи смартфонов Samsung на качественно новый уровень, ведь целый ряд нововведений в ОС делал ее,опятже, чрезвычайно схожим с Android OS. Почему Tizen OS потерпела поражение на рынке смартфонов? Видимо по той самой причине, что и ряд других ОС Sailfish OS, Firefox OS, LiMo и тд. Все эти системы были достаточны подобны друг другу - политика развития в сторону открытости, упрощение жизни разработчикам ПО, кроссплатформенность, а это в свою очередь стало для них роковым фактором. Не сумев заинтересовать массового покупателя чем-то уникальным, новым в череде однотипных ОС победу одержала чуть более успешная Android OS, которая к слову также была далека от идеала в те далекие времена.

Имея такие разные биографии Tizen OS и webOS должно было объединить то, что они обе канут в лето вместе с множеством других ОС. Однако, связало их несколько другое обстоятельство.

Корейский гамбит

Удивительна история. Еще 50 лет тому назад Южная Корея являлась откровенно маргинальным, марионеточным государством. Как бы мы сейчас сказали - банановая республика. В тоже время КНДР довольно успешно строила плановую экономику советского типа. Даже еще в 70х годах большенство побегов к "оккупированному" соседу происходило именно с юга. Гонимые тотальной коррупцией и как следствие нищетой немало корейцев выбирали стабильность на "севере". Но мир не стоит на месте.

Сейчас Южная Корея является лидером, а то и монополистом, в целого ряда важнейших секторов общемировой экономики. В разрезе ИТ невозможно не упомянуть о корпорациях Samsung и LG. Именно они то и сыграли главную роль в современном положении Tizen OS и webOS. В мире разделенном между адептами двух религий iOS и Android OS, само существование еще двух независимых, локально успешных платформ выглядит не менее интригующе как и существование коммунистической КНДР во всецело капиталистическом мире.

В 2012 году, когда webOS уже окончательно потерпела фиаско, а с ней разом и компания Palm, ситуацией как нельзя луче воспользовалась корейская корпорация LG выкупив все права на использование загибающейся ОС. Особенно подогревало интерес к этому приобретению то обстоятельство, что будучи довольно крупным производителем смартфонов LG мог бы вдохнуть новую жизнь во все еще весьма конкурентный продукт . Однако в планы корпорации вовсе не входило воскрешать из забвения павшего героя ведущего свою родословную еще из 90х. Проблема которую должна была решить покупка webOS состояла в отсутствии у LG собственной программной платформы для управления новомодными девайсами производимыми корпорацией. В свое время упустив из виду тот момент, что все чаще в названиях всевозможной техники появляется слово "Smart", LG столкнулась с необходимостью разработки с нуля собственного продукта, либо покупкой уже готового решения, для управления новомодными умными девайсами. Конечно оставался вариант пойти по пути мелких производителей и начать работу по адаптации к выпускаемой продукции Android OS, однако размеры компании, как и разнообразие выпускаемой номенклатуры товаров, диктовали необходимость создания собственной единой программой среды, которая должна была быть достаточно гибкой не только для уже существующей техники, а и для будущих перспективных разработок. Покупкой webOS остались довольны все, как получившее новые смыслы подразделение Palm так и оторвавшая за бесценок кучу патентов на полностью рабочий продукт корпорация LG.

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

Не смартфоном единым

Как-то довелось мне быть свидетелем повествования одного отставного военного инженера. Человек еще в 80х принимал участие в разработке "мозгов" межконтинентальных баллистических ракет. Поскольку основой безопасности страны советов были ядерные "щит и меч", внимание уделяемое разработке систем наведения, управления, принятия локальных решений "умными ракетами" было на самом высоком уровне. Со слов отставника, ресурсы выделяемые на эти программы лимитировались не более чем здравым смыслом, да и то не всегда. Но даже в таких "тепличных" условиях стоял целый ряд преград к достижению поставленных к ТТХ вооружения. Вызваны они были в первую очередь низким уровнем развития электронной компонентной базой. На то время в мире просто не существовало достаточно компактных, производительных ЭВМ для реализации всех предъявляемых к блоку управления "хотелок". Пытаясь увязать воедино уровень существующей электроники и предъявляемых требований единственным выходом для конструкторского бюро было максимально оптимизировать/упростить логику принятия решений встроенной ЭВМ. С одной стороны такая реализация изделия существенно повышала риск принятия системой управления ракеты неправильного решения, уже вовремя ее полета, что должно было приводить к провалу ее летного задания и включения системы самоликвидации, с другой стороны успешность поставленной задачи должна была достигаться за счет количества производимых запусков по выбранной цели, в общем-то достаточно рабочей системы.

В современном мире 5 нанометрового технологического процесса, где по вычислительным возможностям бюджетный смартфон превосходит суперкомпьютеры из 90х, задача по созданию максимально эффективного ПО не стоит так остро. Не ЦП, не встроенная память "железа" практически не лимитируют современные операционные системы, в то же время на первое место выходят такие вопросы к ОС как удобство использования, безопасность, универсальность, гибкость в настройке интерфейса. Как оказалось всем этим требованиям два новоиспеченных корейца вполне соответствуют.

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

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

Возможен ли "камбэк" в мир смартфонов?

В современном мире где 85% смартфонов работают под управлением Android OS, а оставшиеся 15% принадлежат iOS сложно представить появление нового успешного игрока. И дело тут не столько в "совершенстве" существующих операционных системах. Основная причина скорее лежит в плоскости отсутсвия необходимости в появлении новых ОС. Рынок мобильных программных платформ целиком и полностью удовлетворен существующими. Более того соотношение 15/85 между двумя современными монополистами также, скорее всего, существенно не изменится, даже в условиях появления новых игроков. Ведь, если более детально рассмотреть целевую аудиторию двух формальных конкурентов iOS и Android OS мы увидим, что она не слишком и конкурентна. И Google, и Apple "сожрали" своих истинных соперников еще лет 10 тому назад. Истинная борьба за клиента у iPhone развернулась, в свое время, с компанией BlackBerry, которая продвигала максимально защищенный продукт из премиум сегмента, в то время когда Symbian, Palm, Windows Mobile устанавливались в своей массе на абсолютно иного класса аппараты. Точно также и Android OS сражалась за наследие доживающей последние дни Symbian, в первую очередь, среди себе подобных открытых платформ.

Недавняя санкционная заваруха вокруг китайских ИТ-гигантов породила прецедент серьезной дискуссии вокруг необходимости создания альтернативы операционным системам так или иначе подконтрольным правительству одной страны. В этом ключе оказалось, что существующая Harmony OS не слишком и существующая. Те же Tizen OS и webOS, так же требуют доработок и существенных капиталовложении в раскрутку от их корейских владельцев, тогда как китайское правительство готово в принципе выделять на такое благое дело ресурсы, но не готово их выделять зарубежным компаниям. На данный момент публичная дискуссия вокруг альтернативных мобильных платформ замялась, как замялись и угрозы применения санкций. В то же время китайские компании сделали из происходящего выводы и пошли по пути своих корейских соседей. Развивая собственные платформы с перспективой их расширенного применения на бытовой технике, разного рода консолях, мультимедиа через какое-то время это позволит отточить саму ОС и создать целую программную среду для ее существования. Очевидно, что процесс этот также займет годы.

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

Куда заведут нас кривые дороги технологического прогресса одному Богу известно. В этом русле политические перипетии между двумя сверхдержавами может быть даже подтолкнут к появлению принципиально новых гаджетов, которые "обнулят" монополию существующих ОС. Главное в этой истории, что бы политика не стала ручным тормозом развития технологий и не отдаляла нас от долгожданного светлого будущего.

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

Так получилось, что VPN-клиенты я делал намного чаще, чем пользовался ими по прямому назначению. В 2020 году почти каждый месяц я стабильно получал предложение о создании быстрого, удобного и безопасного. Одни предлагали два сервера, оба из которых платные. Другие давали выбор из 50 стран и возможность подключаться сразу к 4. Несмотря на разный подход, у этих приложений одинаковые паттерны.

Ниже я постарался описать все самое важное, не заостряя внимание на деталях.

Privacy, разрешения

Стандартная процедура, без которой мы не можем предоставить свои услуги. Даем ее сразу после Splash screen. Чем быстрее пользователь разберется с процедурой и забудет о ней, тем раньше он воспользуется приложением. Поэтому мы делаем привычный Agree внизу экрана и нативный Allow, который отпушит в настройки и вернет назад.

Я также слышал, что Privacy принимается пользователем в момент скачивания и все эти экраны не нужны. Тем не менее, VPN-приложений без них я еще не видел.

Кнопка

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

Статус подключения. С одной стороны, это элементарно и понятно. Если подключено, напиши подключено, выдели цветом кнопку. Однако, я часто натыкался на приложения, которые отображают статус индикатором сбоку или интересной иллюстрацией, смысл которой известен только дизайнеру и заказчику. Помните, что далеко не все power users.

Одно слово и противоположный цвет. Все довольны, всем понятно.

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

Список серверов

Переходим к нему только сейчас, так как, по большому счету, это уже другой экран. Делаем либо обычный ModalVC, который временами маскируется под вью (поверх кнопки), либо отдельный ViewController (другой экран). Зависит от желания и предпочтений.

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

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

Время подключения.Встречал почти так же редко, как и информацию о скорости, однако в отличие от нее, практического применения таймеру я так и не нашел. Ни личный опыт, ни опросы, ни диалог с коллегами не дали мне ответ на вопрос: Эм, я подключен уже 3 минуты. Что дальше?. Жить это не мешает, но и толка от этого нет. Расскажите, что Вы думаете на этот счет, мне интересно.

Карта

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

Встроенная покупка

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

Другое

Настройки, поддержка, Q&A, восстановление покупок и далее по списку. Все, что сделает жизнь пользователя немного легче. Встречается в 90% VPN-приложений. Остальные 10% вполне обходятся без этого.

Пожалуйста

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

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

В заключение

Это основное, что важно знать про дизайн VPN-приложения. Мы не учитываем красивый фирменный стиль, правильные анимации и приветливый UI. Это тоже важно, и для многих пользователей может стать определяющим в выборе. У нас Starter pack. Реализовав этот список, приложение можно отправлять в App Store и Google Play.

Хайди хо, Кайл!

Меня зовут Диана и я бизнес-аналитик в компании Surf. В прошлом году я закончила бакалавриат факультета компьютерных наук в ВГУ: это дало мне базовые теоретические знания. Однако теория мало применима без практики: теперь набиваю шишки в настоящих проектах.

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

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

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

Не бойтесь задавать больше вопросов и просить уточнений

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

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

• На чьей стороне будет реализована логика: фронта, middleware, бэка?

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

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

• Касаются ли вашей стороны эти требования или от вас никаких доработок и не потребуется?

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

Проверяйте и перепроверяйте выполнение договорённостей

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

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

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

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

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

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

Пример из жизни

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

Я не акцентировала внимание бэкендеров и продакт оунера на том, насколько важно, чтобы бэк присылал нам этот признак. Когда фича должна была уже уйти в разработку, этого признака всё ещё не было и в помине, потому что ни бэк, ни сторонний сервис, к API которого мы обращались, не разработали его.

Из-за этого процесс задержался ещё на неделю, потому что пришлось потратить много времени на повторное обсуждение. В итоге решили кнопку отображать всегда:)

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

Уточняйте, как сделать проще

Бывает, что бизнес-аналитику реализация фичи кажется удобной. Он предлагает её разработчику, а в ответ получает: Чё-то сложно, давай по-другому?. Это нормально: взгляды аналитика и разработчика на реализацию фичи могут разительно отличаться: разработчик понимает, что ему хотят втюхать что-то сложное и заморочное, и идёт в отказ.

Если бизнес-аналитику не хватает опыта, чтобы оценить, насколько сложен вариант реализации, лучше сразу прийти к разработчикам и посоветоваться с ними. Иначе потом придется проходить новый круг ада: обсуждать изменения. Кроме того, это может сдвинуть сроки реализации: не нужно объяснять, почему это плохо:)

Френдли ремайндер

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

Будьте внимательным к потенциально проблемным требованиям

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

Уточните (если нужно, несколько раз), правильно ли вы поняли, что ваша задача просто добавить картинку котика на экран. Может оказаться, что добавить нужно обязательно чеширского кота, а ещё он должен улыбаться в момент, когда вы моргаете. Я специально привела утрированный пример.

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

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

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

Как определить, что перед вами задача-оборотень, которая может превратиться из человечной в дикую? По количеству непоняток. Берегитесь, если:

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

• Не очевидна инициализация флоу и переход между экранами.

• Нет четкого понимания логики.

Например, несколько месяцев назад мы начали обсуждение фичи без определённых требований. У продакт-оунера не было четкого понимания, что должно получиться в итоге. Это стоило нам многих часов созвонов-обсуждений и несколько раз перекроенного ТЗ.

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

Пример

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

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

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

_______

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

Вот и всё, мои маленькие хоббиты. Я поделилась с вами своей мудростью, теперь вы сами по себе. Не дрейфте, не теряйтесь, будьте настойчивы и внимательны. В добрый путь!

Привет! На связи компанияKODE. Мы занимаемся разработкой мобильных приложений, голосовых интерфейсов, IoT и других цифровых решений для государства и крупного бизнеса в России и Европе с 2013 года.

Руководители наших отделов собрали полноценную библиотеку IT-компании: сайты, блоги, книги, онлайн-курсы, подкасты, Telegram- и YouTube-каналы. Подборка будет полезна менеджерам, аналитикам, разработчикам, дизайнерам и QA.

Направления:

• Проджект-менеджмент.

• Аналитика.

• UX/UI-дизайн.

• Android.

• iOS.

• Backend.

• Frontend.

• QA.

• DevOps.

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

Проджект-менеджмент

Сайты:

• Блог Школы Менеджеров Стратоплан.

• Wait But Who блог об управлении и общечеловеческих темах.

Книги:

• Подборки книг с рецензиями agile-коуча Алексея Пименова.

• Панкратов В. Чёрная книга менеджера.

• Орлов А. Белая книга менеджера.

• Дэниел Гоулман. Эмоциональный интеллект.

• Хенссон Фрайд. Rework. Бизнес без предрассудков.

• Ицхак Адизес. Идеальный руководитель. Почему им нельзя стать и что из этого следует.

• Джим Кэмп. Сначала скажите Нет.

• Гэвин Кеннеди. Договориться можно обо всём.

• PMI PMBoK методология управления проектами.

Курсы:

• Менеджмент проектов и работа с людьмиот Школы Менеджеров Стратоплан.

• Полный курс подготовки PMP.

YouTube-каналы:

• Иван Селиховкин интервью с экспертами и записи выступлений о проектном управлении.

• Максим Дорофеев о психологии умственного труда и личной эффективности.

Telegram-каналы:

• Psilonsk канал Сергея Колганова об управлении проектами и продуктами.

• Селиховкин о проектном управлении в другом формате.

Аналитика

Книги:

• Прерва А., Иванова В. Путь аналитика. Практическое руководство IT-специалиста.

• Карл Вигерс. Разработка требований к программному обеспечению.

• Донелли Медоуз. Азбука системного мышления.

• Карл Андерсон. Аналитическая культура. От сбора данных до бизнес-результатов.

• Богачев А. Графики, которые убеждают всех.

• Дуглас У. Хаббард. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе.

• Левенчук А. Системное мышление.

Курсы:

• Системное мышление курс Анатолия Левенчука на Coursera.

• Постановка задачи на разработку ПОна Stepik.

Telegram-каналы:

• Banana Analyst канал аналитика KODE Анны Денисовой о работе с данными и аналитике в разработке цифровых продуктов.

• Бизнес-анализ & IT.

• Product Analytics актуальные материалы по продуктовой аналитике.

• Интернет-аналитика.

UX/UI-дизайн

Сайты:

• Подборки советов Бюро Горбунова.

• Студия Лебедева.

• Дизайн-паб святыня русскоязычного медиума.

Книги:

• Бирман И. Пользовательский интерфейс.

• Горбунов А. Типографика и вёрстка.

• Ильяхов М.Пиши, сокращай+Ясно, понятно.

• Дональд Норман.Дизайн привычных вещей+Дизайн вещей будущего.

• Пол Рэнд. Дизайн: Форма и хаос.

• Йоханнес Иттен.Искусство цвета+Искусство формы.

• Ян Чихольд.Новая типографика+Облик книги.

• Йозеф Мюллер-Брокманн. Модульные сетки в графическом дизайне.

• Тим Харровер. Настольная книга газетного дизайнера.

• Эдвард Тафти. Представление информации.

• Генрих Альтшуллер. Найти идею.

• Дитер Рамс. 10 правил хорошего дизайна.

• Королькова А. Живая типографика(опубликована в открытом доступе).

• Фитцпатрик Р. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?

• Алан Купер об интерфейсах. Психбольница в руках пациентов.

• Виктор Папанек. Дизайн для реального мира.

• Майк Монтеро. Дизайн это работа.

• Бред Фрост. Атомарный дизайн.

Курсы:

• Графический дизайн специализация на Coursera.

• Школа мобильного дизайнаот Яндекса.

• Управление проектами и продуктомот Яндекса.

• Дизайн мобильных приложенийот Redmadrobot.

• Дизайн мобильных приложенийот Нетологии.

• Дайджест продуктового дизайнера Юрия Ветрова.

• Bang Bang Education онлайн-школа дизайна и иллюстрации.

• Гайдлайны наMaterial Design.

Фильмы:

• 33 слова о дизайне глазами российских дизайнеров.

• 100 лет дизайна документальный фильм о развитии дизайна.

• Современный российский дизайн о последних 20 годах индустрии.

YouTube-каналы:

• Mail.ru x Dribbble MeetUp о дизайне от команды Mail.ru Group.

• Академия Яндекса лекции из курсов различных школ Яндекса, в том числе о дизайне.

Android-разработка

Сайты:

• Developing Android Appsна Reddit новости из мира Android.

• Блог Android Developers Backstageс подкастами и полезными ссылками.

Книги:

• Фредерик Брукс. Мифический человеко-месяц о процессах в разработке.

• Роберт Мартин. Чистая архитектура об организации кодовой базы.

• Хориков В. Принципы юнит-тестирования.

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

Курс:

• Видеокурс по мобильной разработкеот создателя PRISMA.

Подкасты:

• Fragmented подкаст о том, как стать лучшим разработчиком ПО.

• Сушите вёсла о разработке, аналитике, тестировании и других аспектах создания приложений.

• CoRecursive истории, скрывающиеся за кодом, от экспертов в мире разработки.

• Signals And Threads интервью о тонкостях разработки с инженерами из глобальной торговой компании Jane Street.

• Software Engineering Radio еженедельные беседы о ПО.

• Microsoft Research Podcast о передовых технологиях Microsoft Research.

Telegram-каналы:

• Android Guards чат о безопасности Android.

• Android Good Reads полезные статьи, видео и новости.

Twitter:

• Руководитель Android-разработки в CuvvaАдам Беннетт.

• Разработчик GitHubАлексис Кинг.

• Разработчик ПО в MicrosoftДэвид К.

• Android-разработчик вAuto.ruМиша Левченко.

• Разработчик в Cash AppАдам Эрб.

• Android-разработчикСакет Нараян.

• Инженер ПО в GoogleЛеланд Ричардсон.

• Технический руководитель в SquareРальф Вондрачек.

• Руководитель проектов в JetBrainsРоман Елизаров.

• Физик, математик, инженер ПОБартош Милевски.

iOS-разработка

Сайты:

• Издание Swift Talk видео о разработке на Swift.

• Digest MBLT DEV еженедельная подборка новостей.

• iOS Dev Weekly свежие новости, статьи и гайды.

Книги:

• Документация поSwiftот Apple (перевод).

• Роберт Мартин. Чистый код.

• Эрик Фримен, Элизабет Робсон. Паттерны проектирования.

Курсы:

• Онлайн-коллекция Raywenderlich гайды по программированию.

• Классический курс по разработкеот Стэнфордского университета.

Подкаст:

• Подлодка еженедельное аудиошоу о разработке.

YouTube- и Telegram-каналы:

• YouTube-каналПола Хадсонапо SwiftUI.

• Telegram-каналdeprecated чат для новичков, где разбирают сложные для них вопросы.

Backend-разработка

Книги:

• Дональд Э. Кнут. Искусство программирования.

• Стив Макконнелл. Совершенный код.

• Алан Донован, Брайан Керниган. Язык программирования Go.

• Джеффри Фридл. Регулярные выражения.

• Новиков Ф. А. Дискретная математика для программистов.

• Марк Лутц. Изучаем Python.

• Мартин Клеппман. Высоконагруженные приложения. Программирование, масштабирование, поддержка.

YouTube-каналы:

• Доклады с IT-конференции HighLoad++ на YouTube.

• YouTube-канал Хусейна Нассера о разработке ПО с примерами.

Telegram-каналы:

• Официальный Telegram-канал Хабра.

• ClickHouse не тормозит.

Frontend-разработка

Ресурсы и сайты:

• Современный учебник JavaScript.

• V8 движок JavaScript с открытым исходным кодом.

• MDN Web Docs ресурсы для разработчиков от разработчиков.

• JavaScript Weekly свежие статьи, новости и проекты по JavaScript.

Блоги:

• Дэн Абрамов личный блог разработчика, одного из авторов Redux.

• Katz Got Your Tongue статьи Иегуды Каца, соавтора Ember.js и ответственного за разработку плагинов в jQuery.

Книги:

• Серия книг Вы не знаете JS(перевод).

• Марейн Хавербеке. Выразительный JavaScript.

• Джон Резиг. Секреты JavaScript ниндзя.

• Борис Чёрный. Профессиональный TypeScript. Разработка масштабируемых JavaScript-приложений.

Подкасты:

• FrontoWeek важные события фронтенда за неделю.

• Веб-стандарты ещё один новостной канал.

• UnderJS обсуждения JS на Frontend и Backend, React Native, Linux.

• Фронтенд Юность вся правда о фронтенд-разработке.

• Frontend Weekend интервью с известными людьми из веб-разработки.

• Пятиминутка React подкаст о React и смежных технологиях в мире JavaScript и фронтенда.

• kamyshev.talk об архитектуре, коде и гибких навыках.

YouTube-каналы:

• АйТи Синяк канал разработчика с семилетним стажем в HTML, CSS и JS.

• Фронтенд школа разработки интерфейсов.

• Mozilla Developer ролики для веб-дизайнеров и разработчиков.

• Канал Тимура Шемсединова открытые лекции, конференции и школы по программной инженерии, JavaScript и Node.js.

Telegram-каналы:

• FrontoWeek: Недельный дайджест.

• For Web фронтенд, дизайн, программирование.

• Вебня JS VMs, спецификации, встречи.

• Веб-стандарты ежедневные новости и события фронтенда от сообщества веб-разработчиков.

QA

Сайты:

• ПорталSoftware Testing сотни тематических статей, подборок книг по тестированию и обзор новостей отрасли.

• БлогQCoder концентрат полезных знаний.

Курсы:

• Python: основы и применения.

• Автоматизация тестирования с помощью Selenium и Python.

Telegram-каналы:

• Серьёзный тестировщик кроме полезной информации, в описании собраны разные болталки: для джуниоров, русскоговорящего сообщества, о компаниях и деньгах в QA, для поиска работы и сотрудников.

• Тестировщик от бога подборки статей, роликов, инструментов и новые фичи со всего интернета.

• Радио QA неформальный канал о тестировании и QA.

• Load & Performance о нагрузочном тестировании.

• QA ninjas подборки статей из Хабра, YouTube-роликов и интервью с практикующими тестировщиками.

• QA Автоматизация.

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

YouTube-каналы:

• Любительский канал Алексея Баренцева полезные видео для начинающих тестировщиков.

• QAGuild об автоматизации тестирования и ИТ.

• Heisenbug доклады с международной технической QA-конференции.

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

DevOps

Книги:

• Официальное руководство Cisco по подготовке к сертификационным экзаменам CCENT/CCNA ICND1 100-101.

• MikroTik RouterOS. Руководство пользователя.

• Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы.

• Дуглас Камер. Сети TCP/IP. Принципы, протоколы и структура.

• Скляров. О. К. Волоконно-оптические сети и системы связи.

• Сваруп Читлур. A Byte of Python, или Укус питона руководство по Python для начинающих.

• Арнольд Роббинс. Bash. Карманный справочник для системного администратора.

• Рэндал Шварц. Изучаем Perl.

• UNIX и LINUX. Руководство системного администратора.

• Барон Шварц, Пётр Зайцев, Вадим Ткаченко. MySQL по максимуму.

• Джез Хамбл, Дейвид Фарли. Непрерывное развёртывание ПО автоматизация процессов сборки, тестирование и внедрения новых версий программ.

• Джон Арундел, Джастин Домингус. Kubernetes для DevOps развёртывание, запуск и масштабирование в облаке.

• Роланд Хасс. Паттерны Kubernetes шаблоны разработки собственных облачных приложений.

• Джен Ким, Патрик Дебуа и др. Руководство по DevOps. Как добиться гибкости, надёжности и безопасности мирового уровня в технологических компаниях.

• Евгений Брикман. Terraform. Инфраструктура на уровне кода.

• Лорин Хоштейн, Рене Мозер. Запускаем Ansible.

Telegram-каналы:

• Книги для Системного Администратора.

• Слёрм вечерняя школа с трёхдневными интенсивами и видеокурсы.

• Кибер****** о технологии и информационной безопасности.

• DaRk NeT 911 книги по практической ИБ.

Не забудьте поделиться с коллегами и теми, кому может быть интересна эта подборка!

Привет! На связи компанияKODE. Мы занимаемся разработкой мобильных приложений, голосовых интерфейсов, IoT и других цифровых решений для государства и крупного бизнеса в России и Европе с 2013 года.

Руководители наших отделов собрали полноценную библиотеку IT-компании: сайты, блоги, книги, онлайн-курсы, подкасты, Telegram- и YouTube-каналы. Подборка будет полезна менеджерам, аналитикам, разработчикам, дизайнерам и QA.

Направления:

• Проджект-менеджмент.

• Аналитика.

• UX/UI-дизайн.

• Android.

• iOS.

• Backend.

• Frontend.

• QA.

• DevOps.

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

Проджект-менеджмент

Сайты:

• Блог Школы Менеджеров Стратоплан.

• Wait But Who блог об управлении и общечеловеческих темах.

Книги:

• Подборки книг с рецензиями agile-коуча Алексея Пименова.

• Панкратов В. Чёрная книга менеджера.

• Орлов А. Белая книга менеджера.

• Дэниел Гоулман. Эмоциональный интеллект.

• Хенссон Фрайд. Rework. Бизнес без предрассудков.

• Ицхак Адизес. Идеальный руководитель. Почему им нельзя стать и что из этого следует.

• Джим Кэмп. Сначала скажите Нет.

• Гэвин Кеннеди. Договориться можно обо всём.

• PMI PMBoK методология управления проектами.

Курсы:

• Менеджмент проектов и работа с людьмиот Школы Менеджеров Стратоплан.

• Полный курс подготовки PMP.

YouTube-каналы:

• Иван Селиховкин интервью с экспертами и записи выступлений о проектном управлении.

• Максим Дорофеев о психологии умственного труда и личной эффективности.

Telegram-каналы:

• Psilonsk канал Сергея Колганова об управлении проектами и продуктами.

• Селиховкин о проектном управлении в другом формате.

Аналитика

Книги:

• Прерва А., Иванова В. Путь аналитика. Практическое руководство IT-специалиста.

• Карл Вигерс. Разработка требований к программному обеспечению.

• Донелли Медоуз. Азбука системного мышления.

• Карл Андерсон. Аналитическая культура. От сбора данных до бизнес-результатов.

• Богачев А. Графики, которые убеждают всех.

• Дуглас У. Хаббард. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе.

• Левенчук А. Системное мышление.

Курсы:

• Системное мышление курс Анатолия Левенчука на Coursera.

• Постановка задачи на разработку ПОна Stepik.

Telegram-каналы:

• Banana Analyst канал аналитика KODE Анны Денисовой о работе с данными и аналитике в разработке цифровых продуктов.

• Бизнес-анализ & IT.

• Product Analytics актуальные материалы по продуктовой аналитике.

• Интернет-аналитика.

UX/UI-дизайн

Сайты:

• Подборки советов Бюро Горбунова.

• Студия Лебедева.

• Дизайн-паб святыня русскоязычного медиума.

Книги:

• Бирман И. Пользовательский интерфейс.

• Горбунов А. Типографика и вёрстка.

• Ильяхов М.Пиши, сокращай+Ясно, понятно.

• Дональд Норман.Дизайн привычных вещей+Дизайн вещей будущего.

• Пол Рэнд. Дизайн: Форма и хаос.

• Йоханнес Иттен.Искусство цвета+Искусство формы.

• Ян Чихольд.Новая типографика+Облик книги.

• Йозеф Мюллер-Брокманн. Модульные сетки в графическом дизайне.

• Тим Харровер. Настольная книга газетного дизайнера.

• Эдвард Тафти. Представление информации.

• Генрих Альтшуллер. Найти идею.

• Дитер Рамс. 10 правил хорошего дизайна.

• Королькова А. Живая типографика(опубликована в открытом доступе).

• Фитцпатрик Р. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?

• Алан Купер об интерфейсах. Психбольница в руках пациентов.

• Виктор Папанек. Дизайн для реального мира.

• Майк Монтеро. Дизайн это работа.

• Бред Фрост. Атомарный дизайн.

Курсы:

• Графический дизайн специализация на Coursera.

• Школа мобильного дизайнаот Яндекса.

• Управление проектами и продуктомот Яндекса.

• Дизайн мобильных приложенийот Redmadrobot.

• Дизайн мобильных приложенийот Нетологии.

• Дайджест продуктового дизайнера Юрия Ветрова.

• Bang Bang Education онлайн-школа дизайна и иллюстрации.

• Гайдлайны наMaterial Design.

Фильмы:

• 33 слова о дизайне глазами российских дизайнеров.

• 100 лет дизайна документальный фильм о развитии дизайна.

• Современный российский дизайн о последних 20 годах индустрии.

YouTube-каналы:

• Mail.ru x Dribbble MeetUp о дизайне от команды Mail.ru Group.

• Академия Яндекса лекции из курсов различных школ Яндекса, в том числе о дизайне.

Android-разработка

Сайты:

• Developing Android Appsна Reddit новости из мира Android.

• Блог Android Developers Backstageс подкастами и полезными ссылками.

Книги:

• Фредерик Брукс. Мифический человеко-месяц о процессах в разработке.

• Роберт Мартин. Чистая архитектура об организации кодовой базы.

• Хориков В. Принципы юнит-тестирования.

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

Курс:

• Видеокурс по мобильной разработкеот создателя PRISMA.

Подкасты:

• Fragmented подкаст о том, как стать лучшим разработчиком ПО.

• Сушите вёсла о разработке, аналитике, тестировании и других аспектах создания приложений.

• CoRecursive истории, скрывающиеся за кодом, от экспертов в мире разработки.

• Signals And Threads интервью о тонкостях разработки с инженерами из глобальной торговой компании Jane Street.

• Software Engineering Radio еженедельные беседы о ПО.

• Microsoft Research Podcast о передовых технологиях Microsoft Research.

Telegram-каналы:

• Android Guards чат о безопасности Android.

• Android Good Reads полезные статьи, видео и новости.

Twitter:

• Руководитель Android-разработки в CuvvaАдам Беннетт.

• Разработчик GitHubАлексис Кинг.

• Разработчик ПО в MicrosoftДэвид К.

• Android-разработчик вAuto.ruМиша Левченко.

• Разработчик в Cash AppАдам Эрб.

• Android-разработчикСакет Нараян.

• Инженер ПО в GoogleЛеланд Ричардсон.

• Технический руководитель в SquareРальф Вондрачек.

• Руководитель проектов в JetBrainsРоман Елизаров.

• Физик, математик, инженер ПОБартош Милевски.

iOS-разработка

Сайты:

• Издание Swift Talk видео о разработке на Swift.

• Digest MBLT DEV еженедельная подборка новостей.

• iOS Dev Weekly свежие новости, статьи и гайды.

Книги:

• Документация поSwiftот Apple (перевод).

• Роберт Мартин. Чистый код.

• Эрик Фримен, Элизабет Робсон. Паттерны проектирования.

Курсы:

• Онлайн-коллекция Raywenderlich гайды по программированию.

• Классический курс по разработкеот Стэнфордского университета.

Подкаст:

• Подлодка еженедельное аудиошоу о разработке.

YouTube- и Telegram-каналы:

• YouTube-каналПола Хадсонапо SwiftUI.

• Telegram-каналdeprecated чат для новичков, где разбирают сложные для них вопросы.

Backend-разработка

Книги:

• Дональд Э. Кнут. Искусство программирования.

• Стив Макконнелл. Совершенный код.

• Алан Донован, Брайан Керниган. Язык программирования Go.

• Джеффри Фридл. Регулярные выражения.

• Новиков Ф. А. Дискретная математика для программистов.

• Марк Лутц. Изучаем Python.

• Мартин Клеппман. Высоконагруженные приложения. Программирование, масштабирование, поддержка.

YouTube-каналы:

• Доклады с IT-конференции HighLoad++ на YouTube.

• YouTube-канал Хусейна Нассера о разработке ПО с примерами.

Telegram-каналы:

• Официальный Telegram-канал Хабра.

• ClickHouse не тормозит.

Frontend-разработка

Ресурсы и сайты:

• Современный учебник JavaScript.

• V8 движок JavaScript с открытым исходным кодом.

• MDN Web Docs ресурсы для разработчиков от разработчиков.

• JavaScript Weekly свежие статьи, новости и проекты по JavaScript.

Блоги:

• Дэн Абрамов личный блог разработчика, одного из авторов Redux.

• Katz Got Your Tongue статьи Иегуды Каца, соавтора Ember.js и ответственного за разработку плагинов в jQuery.

Книги:

• Серия книг Вы не знаете JS(перевод).

• Марейн Хавербеке. Выразительный JavaScript.

• Джон Резиг. Секреты JavaScript ниндзя.

• Борис Чёрный. Профессиональный TypeScript. Разработка масштабируемых JavaScript-приложений.

Подкасты:

• FrontoWeek важные события фронтенда за неделю.

• Веб-стандарты ещё один новостной канал.

• UnderJS обсуждения JS на Frontend и Backend, React Native, Linux.

• Фронтенд Юность вся правда о фронтенд-разработке.

• Frontend Weekend интервью с известными людьми из веб-разработки.

• Пятиминутка React подкаст о React и смежных технологиях в мире JavaScript и фронтенда.

• kamyshev.talk об архитектуре, коде и гибких навыках.

YouTube-каналы:

• АйТи Синяк канал разработчика с семилетним стажем в HTML, CSS и JS.

• Фронтенд школа разработки интерфейсов.

• Mozilla Developer ролики для веб-дизайнеров и разработчиков.

• Канал Тимура Шемсединова открытые лекции, конференции и школы по программной инженерии, JavaScript и Node.js.

Telegram-каналы:

• FrontoWeek: Недельный дайджест.

• For Web фронтенд, дизайн, программирование.

• Вебня JS VMs, спецификации, встречи.

• Веб-стандарты ежедневные новости и события фронтенда от сообщества веб-разработчиков.

QA

Сайты:

• ПорталSoftware Testing сотни тематических статей, подборок книг по тестированию и обзор новостей отрасли.

• БлогQCoder концентрат полезных знаний.

Курсы:

• Python: основы и применения.

• Автоматизация тестирования с помощью Selenium и Python.

Telegram-каналы:

• Серьёзный тестировщик кроме полезной информации, в описании собраны разные болталки: для джуниоров, русскоговорящего сообщества, о компаниях и деньгах в QA, для поиска работы и сотрудников.

• Тестировщик от бога подборки статей, роликов, инструментов и новые фичи со всего интернета.

• Радио QA неформальный канал о тестировании и QA.

• Load & Performance о нагрузочном тестировании.

• QA ninjas подборки статей из Хабра, YouTube-роликов и интервью с практикующими тестировщиками.

• QA Автоматизация.

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

YouTube-каналы:

• Любительский канал Алексея Баренцева полезные видео для начинающих тестировщиков.

• QAGuild об автоматизации тестирования и ИТ.

• Heisenbug доклады с международной технической QA-конференции.

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

DevOps

Книги:

• Официальное руководство Cisco по подготовке к сертификационным экзаменам CCENT/CCNA ICND1 100-101.

• MikroTik RouterOS. Руководство пользователя.

• Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы.

• Дуглас Камер. Сети TCP/IP. Принципы, протоколы и структура.

• Скляров. О. К. Волоконно-оптические сети и системы связи.

• Сваруп Читлур. A Byte of Python, или Укус питона руководство по Python для начинающих.

• Арнольд Роббинс. Bash. Карманный справочник для системного администратора.

• Рэндал Шварц. Изучаем Perl.

• UNIX и LINUX. Руководство системного администратора.

• Барон Шварц, Пётр Зайцев, Вадим Ткаченко. MySQL по максимуму.

• Джез Хамбл, Дейвид Фарли. Непрерывное развёртывание ПО автоматизация процессов сборки, тестирование и внедрения новых версий программ.

• Джон Арундел, Джастин Домингус. Kubernetes для DevOps развёртывание, запуск и масштабирование в облаке.

• Роланд Хасс. Паттерны Kubernetes шаблоны разработки собственных облачных приложений.

• Джен Ким, Патрик Дебуа и др. Руководство по DevOps. Как добиться гибкости, надёжности и безопасности мирового уровня в технологических компаниях.

• Евгений Брикман. Terraform. Инфраструктура на уровне кода.

• Лорин Хоштейн, Рене Мозер. Запускаем Ansible.

Telegram-каналы:

• Книги для Системного Администратора.

• Слёрм вечерняя школа с трёхдневными интенсивами и видеокурсы.

• Кибер****** о технологии и информационной безопасности.

• DaRk NeT 911 книги по практической ИБ.

Не забудьте поделиться с коллегами и теми, кому может быть интересна эта подборка!

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

А теперь представьте, что вы отвечаете за рост вовлеченности на Ютубе. У вас миллиарды пользователей, сложная экосистема. Как узнать, повышается ли вовлеченность пользователей? Почему кто-то использует ваш продукт больше, а кто-то меньше? И что вообще такое эта вовлеченность?

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

• Измерять выход (например, успешность продукта): количественно оценивать движение в направлении бизнес-цели.

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

• Принимать решения: проводить эксперименты и решать, как должен развиваться продукт.

• Реагировать и адаптироваться: метрики предупреждают о проблемах с работоспособностью продукта и о тенденциях, которые ставят под угрозу наши цели.

• Концентрировать усилия: направлять работу команды в одном направлении.

Типы метрик для продуктовых команд

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

Успех, эмпатия и работоспособность

• Успех (измерение выхода). В правильном ли направлении движется продукт? В чем причины?

• Эмпатия. Можем ли мы определить смысл метрик? Знаем ли мы, что пользователи думают о продукте?

• Работоспособность. Контролируем ли мы состояние продукта? У какого процента пользователей он работает надежно?

Истинный север, указатели и контрольные метрики

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

• Spotify общее время прослушивания.

• Facebook количество активных пользователей в месяц (MAU).

• Slack количество активных пользователей в день (DAU).

Указатели это метрики, которые не определяют успех продукта, однако (вспомним аналогию с черным ящиком) помогают понять, почему истинный север или иные важные части продукта, которые нужно отслеживать, движутся в определенном направлении. Например, если истинный север для Spotify общее время прослушивания, то указателями могут быть (1) количество уникальных пользователей, (2) количество уникальных композиций, прослушанных одним пользователем, и (3) средняя продолжительность композиции.

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

Факты и смысл

• Количественные метрики характеризуются высокими объемами и низкой связью с контекстом; они дают фактические данные и помогают понять поведение пользователей: это количество активных пользователей в день (DAU), отток, вовлеченность, объем продаж ит.д.

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

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

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

Практические советы по работе с метриками

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

Слепо используемые в качестве целей метрики утрачивают смысл

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

1. Коэффициент показ сеанс: процент вошедших в систему пользователей относительно количества открывших экран входа.

2. Коэффициент попытка входа сеанс: процент вошедших в систему пользователей относительно количества воспользовавшихся интерфейсом экрана входа.

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

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

• взрослые технически грамотны, показатель попытка входа сеанс для них составляет 71%,

• пожилые ориентируются хуже, поэтому в их случае это будет 50%.

Вы запускаете эксперимент, который увеличивает количество попыток входа в систему пожилыми. Их доля увеличится, но только 50% таких попыток будут успешными, поэтому используемая в качестве истинного севера метрика попытка входа сеанс снизится с 65% до 63%:

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

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

Метрики должны быть понятными

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

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

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

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

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

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

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

1. Обратимость. Насколько обратимо это решение? Превышает ли цена принятия неправильного решения издержки от ожидания точных данных?

2. Эмпатия. Можно ли заменить нужные данные эмпатией? Без одного из этих ориентиров обойтись можно но без обоих обойтись нельзя.

Резюме. Десять важных вопросов

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

1. Какой цели вы пытаетесь достичь? Какие у вас миссия и видение?

2. Как узнать, что цель достигнута?

3. Как оценивать прогресс в достижении этой цели?

4. Какие действия вам нужны от пользователей и как оценить, выполняются ли они?

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

6. Метрики абсолютные или относительные? Цель привлечь определенное количество пользователей или определенный процент?

7. Как понять, что продукт надежно работает у 99,9% пользователей?

8. Можете ли вы объяснить выбранный истинный север максимум двумя предложениями?

9. Какие контрольные метрики вы отслеживаете в экспериментах?

10. Как пользователи относятся к продукту?

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

Если статья оказалась полезной можете ознакомиться с остальными в блоге reeve.blog, которые появляются там регулярно (более-менее).

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Всем привет. Меня зовут Кирилл Капранов, я руководитель направления системного анализа в компании Sportmaster Lab. 10 марта 2021 года мы с коллегами сделали первый митап по системному анализу, и я хочу поделиться с вами тем, как это было.

Что первым приходит в голову, когда слышишь фразу: "работаю в Спортмастере"? Уверен, у 90% людей промелькнет в голове: "Хм, наверное, продаёт кроссовки". Почему именно эти стереотипы?

Всё просто: в прошлом компания "Спортмастер" делала упор на развитие розничной сети, создание собственного производства, налаживание сети поставок, и, хотя ИТ в этом играло большую роль, знали об этом только внутри компании.

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

• Создание продуктовых команд;

• Создание центров компетенций.

Когда мы трансформировались, было сформировано отдельное ИТ-подразделение, которое получило название Sportmaster Lab. В это подразделение вошли центры компетенции разработки, системного анализа, QA и методологии.

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

Как мы делали SM Lab Analyst Day

Как появилась идея провести митап?

Центр компетенции (далее - ЦК) аналитики появился меньше года назад. За это время ЦК объединил больше сотни сотрудников из 30 разных команд. Мы выработали стандарты, процессы, подходы и до сих пор прорабатываем решения, которые помогают развивать сотрудников и поддерживать развитие компании.

Однажды мы задали себе вопрос : "А кто об этом знает?". Ответ был неприятный, но честный : "Никто, кроме нас".

Ну что ж, приняли. Пора действовать.

Как спланировали

Любая идея начинается с плана. Наш случай не исключение. Мы оформили план в виде следующего списка:

Цель митапа: Формат проведения: Продвижение: Целевое количество людей: Количество докладов: Тайминг: Этапы подготовки: Договоренности:

План готов, а что с ним делать дальше?

Подготовка к митапу

Для себя мы выделили такие этапы подготовки:

• Анонс о проведении митапа на сотрудников ЦК, призыв к действию

  На данном этапе важно донести до сотрудников ценность проведения митапа, а также прояснить все оставшиеся вводные:
  

  • Формат проведения

  • Количество докладов

  • Дата проведения

  • TO-DO list

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

• Сбор заявок на выступление

Часто бывает, что на старте подготовки к митапу докладов нет, а есть только идея и желание. Но как же понять суть доклада, его мессадж? Инструменты для выполнения этой задачи можно объединить в такие структурные блоки*:*

• Идея доклада. Это опыт, трудности или факап, который вдохновил сделать эти выводы.

• Описание. Краткое изложение материала.

• Почему это интересно слушать.

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

В нашем случае удалось немного прочитерить :)

В SM Lab у нас регулярно проходят внутренние клубы, предназначенные для того, чтобы делиться опытом или показывать полезные инструменты, упрощающие жизнь. Поэтому на старте мы имели порядка 8 тем с готовыми докладами.

Ну всё: считай, дело сделано, расходимся! Но нет...

• Отбор докладов

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

То же самое происходит и при проведении ИТ мероприятий. Нужно заинтересовать своего слушателя.

О чем интересно слушать:

• Улучшение процессов (с цифрами)

• Как я могу переиспользовать полученную информацию

• Практический опыт, разбор примера

• Факапы и какие выводы из этого были сделаны

• Как увеличить личную или командную эффективность

О чем слушать не хочется:

• Мы придумали штуку, но мы её не попробовали

• Я прочитал статью или книгу, теперь я вам её перескажу

• Мы тут сделали у себя локальную штуку, послушайте

• Я расскажу всем известную информацию

Мы взяли бритву Оккама и применили эти списки к своим 8 докладам. Таким образом, у нас осталось 6 докладов и 4 спикера. Так как у каждого из двух спикеров было по два доклада, то мы отдали право выбора им. Так получился тот список докладов, который решили рассказывать на нашем митапе. Теперь пора подумать о продвижении.

• Начало продвижения

  Для продвижения любого мероприятия нужны деньги ... на самом деле, не cовсем :). Деньги нужны, но не так много, как вы могли бы подумать, особенно в 2021 году, в эру онлайна.

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

  • Где будет проходить запись на мероприятие

  • Целевая аудитория

  • Инструмент проведения мероприятия

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

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

  И вот теперь, кажется, всё готово! Но нет...

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

  Мы их сформулировали, теперь пора переходить к следующему этапу.

• Тестовые прогоны

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

Проведение митапа

Митап SM Lab analyst day состоялся 10 марта 2021 года. Пик слушателей составлял 200 человек. Среди участников митапа были cотрудники Сбербанка, Tinkoff, Райффайзенбанка, Альфа-Банка, МТС, EPAM, банка Открытие и РТЛабс и многих других компаний.

О чём мы рассказывали:

Пантелеева Елизавета -Работа в Спортмастере на примере проекта "Новый интернет магазин"

Лиза работает системным аналитиком в команде "Новый интернет магазин", которая состоит из 20 сотрудников (системные аналитики, бэкенд и фронтенд-разработчики, тестировщики).

В докладе Лиза затронула следующие моменты:

• Как устроена работа продуктовой команды в компании Спортмастер

• Как мы пришли к продуктовому подходу и какую проблему хотели решить

• Кто и как проводит декомпозицию задач

• Как задача переходит в работу и какие стадии она проходит

• Какова роль системного аналитика

Полуян Артем -Практический кейс замещения аналитиками роли Тестировщик.

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

В докладе Артёма есть ответы на эти вопросы:

• Как команда может остаться без одной из компетенций

• Кто и каким образом может забрать на себя работу в момент поиска специалистов

• Какие подходы в команде опробовали при замещении компетенции

• Как происходил онбординг и обучение новых сотрудников

• Какие выводы сделала команда и сам Артем

• Практические советы по онбордингу нового сотрудника

Заев Артем -Ходим с разработчиками налево!Или Как уменьшить потери на пробелах в бизнес-постановках

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

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

Хахарев Иван -Как мы пришли к Figma или зачем учиться готовить вкусно

Однажды к Ивану в команду пришли новые разработчики и сказали, что макеты это уже прошлый век, и будущее за прототипированием. Так как Ваня человек, который любит изучать новое, он загорелся идеей исследования инструментов прототипирования. В своем докладе он рассмотрел 3 популярных инструмента Axure, Adobe XD и Figma, сравнил их между собой, а также объяснил, почему он выбрал один из них. Бонусом Ваня устроил мини-воркшоп по созданию прототипа.

Заключение

Это был наш первый митап по системному анализу: не всё прошло гладко, как это бывает в первый раз, но мы получили классный опыт проведения подобных мероприятий и рассказали миру инсайдерской информации о системной аналитике в крупном спортивном ритейлере :)

На этом мы не заканчиваем. 20-21 мая мы участвуем в конференции Analyst Days, где выступим с докладами и пообщаемся с единомышленниками на стенде компании.

Нам нравится открыто рассказывать о своей работе. Увидимся на наших новых мероприятиях!

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

Единственное, о чем мы пожалели что не применили это решение раньше.

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

Два года назад, когда мы переходили с RedShift на ClickHouse, количество собираемых аналитических событий (приложение открылось, приложение запросило ленту контента, пользователь просмотрел контент, пользователь поставил смайл (лайк) и так далее) составляло около 5 млрд в сутки. Сегодня это число приближается к 14 млрд.

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

Но перед тем, как агрегировать, сохранить и обработать столько данных, их надо сначала принять и с этим есть свои проблемы. Часть описана в статье о переходе на ClickHouse (ссылка на неё была выше), но есть и другие.

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

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

Но ближе к лету непростого 2020 года ей нашлось применение.

Протокол HTTP, помимо сжатия ответов (о котором знают все, кто когда-либо оптимизировал скорость работы сайтов), позволяет использовать аналогичный механизм для сжатия тела POST/PUT-запросов, объявив об этом в заголовке Content-Encoding. В качестве входящего обратного прокси и балансировщика нагрузки мы используем nginx, проверенное и надёжное решение. Мы настолько были уверены, что он сумеет ко всему прочему ещё и на лету распаковать тело POST-запроса, что поначалу даже не поверили, что из коробки он этого не умеет. И нет, готовых модулей для этого тоже нет, надо было как-то решать проблему самостоятельно или использовать скрипт на Lua. Идея с Lua нам особенно не понравилась, зато это знание развязало руки в части выбора алгоритма компрессии.

Дело в том, что давно стандартизированные алгоритмы сжатия типа gzip, deflate или LZW были изобретены в 70-х годах XX века, когда каналы связи и носители были узким горлышком, и коэффициент сжатия был важнее, чем потраченное на сжатие время. Сегодня же в кармане каждого из нас лежит универсальный микрокомпьютер первой четверти XXI века, оборудованный подчас четырёх- и более ядерным процессором, способный на куда большее, а значит алгоритм можно выбрать более современный.

Выбор алгоритма

Требования к алгоритму были простыми:

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

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

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

4. Permissive лицензия.

Сразу отбросили Brotli, предназначенный для одноразового сжатия статического контента на стороне сервера. По схожей причине решили отказаться от bzip, также ориентированного на статику и большие архивы.

В итоге остановились на алгоритме Zstandard, по следующим причинам:

• Высокая скорость сжатия (на порядок больше, чем у zlib), заточенность на небольшие объёмы данных.

• Хороший коэффициент сжатия при щадящем уровне потребления CPU.

• За алгоритмом стоит Facebook, разрабатывавший его для себя.

• Открытый исходный код, двойная лицензия GPLv2/BSD.

Когда мы увидели первым же в списке поддерживаемых языков JNI, интерфейс вызова нативного кода для JVM, доступный из Kotlin мы поняли, что это судьба. Ведь Kotlin является у нас основным языком разработки как на Android, так и бэкенде. Обёртка для Swift (наш основной язык разработки на iOS) завершила процесс выбора.

Решение на бэкенде

На стороне бэкенда задача была тривиальная: увидев заголовок Content-encoding: zstd, сервис должен получить поток, содержащий сжатое тело запроса, отправить его в декомпрессор zstd, и получить в ответ поток с распакованными данными. То есть буквально (используя JAX-RS container):

// Обёртка над Zstd JNIimport org.apache.commons.compress.compressors.zstandard.ZstdCompressorInputStream;// ...if (  containerRequestContext    .getHeaders()    .getFirst("Content-Encoding")    .equals("zstd")) {  containerRequestContext    .setEntityStream(ZstdCompressorInputStream(      containerRequestContext.getEntityStream()    ))}

Решение на iOS

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

import Foundationimport ZSTDfinal class ZSTDRequestSerializer {    private let compressionLevel: Int32    init(compressionLevel: Int32) {        self.compressionLevel = compressionLevel    }    func requestBySerializing(request: URLRequest, parameters: [String: Any]?) throws -> URLRequest? {        guard let mutableRequest = (request as NSURLRequest).mutableCopy() as? NSMutableURLRequest else {            return nil        }        // ...        mutableRequest.addValue("zstd", forHTTPHeaderField: "Content-Encoding")        if let parameters = parameters {            let jsonData = try JSONSerialization.data(withJSONObject: parameters, options: [])            let processor = ZSTDProcessor(useContext: true)            let compressedData = try processor.compressBuffer(jsonData, compressionLevel: compressionLevel)            mutableRequest.httpBody = compressedData        }        return mutableRequest as URLRequest    }}

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

Впрочем, и снижение объёма трафика было не сильно заметно. Дождавшись, пока новая версия клиента раскатится пошире, мы врубили сжатие на 100% аудитории.

Результат нас, мягко говоря, удовлетворил:

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

То есть мы на четверть сократили весь объём.

Решение на Android

Воодушевлённые, мы запилили сжатие для второй платформы.

// Тут перехватываем отправку события через interceptor и подменяем оригинальный body на сжатый если это запрос к eventsoverride fun intercept(chain: Interceptor.Chain): Response {   val originalRequest = chain.request()   return if (originalRequest.url.toString()               .endsWith("/events")) {      val compressed = originalRequest.newBuilder()            .header("Content-Encoding", "zstd")            .method(originalRequest.method, zstd(originalRequest.body))            .build()      chain.proceed(compressed)   } else {      chain.proceed(chain.request())   }}// Метод сжатия, берет requestBody и возвращает сжатыйprivate fun zstd(requestBody: RequestBody?): RequestBody {   return object : RequestBody() {      override fun contentType(): MediaType? = requestBody?.contentType()      override fun contentLength(): Long = -1 //We don't know the compressed length in advance!      override fun writeTo(sink: BufferedSink) {         val buffer = Buffer()         requestBody?.writeTo(buffer)         sink.write(Zstd.compress(buffer.readByteArray(), compressLevel))      }   }}

И тут нас ждал шок:

Так как доля Android среди нашей аудитории больше, чем iOS, падение составило ещё 45%. Итого, если считать от исходного уровня, мы выиграли суммарно 70% от, напомню, всего входящего трафика в ДЦ.

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

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

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

Два слова, что ещё можно улучшить

У Zstandard есть очень интересная возможность использования предобученного словаря. Если взять достаточно большой объём типичных данных и прогнать по нему сжатие, то можно получить на выходе словарь наиболее высокочастотных вхождений, который затем использовать и при сжатии, и при распаковке.

При этом коэффициент сжатия увеличивается от 10-15% на текстах до 50% на однообразных наборах строк, как у нас. А скорость сжатия даже несколько увеличивается при размере словаря порядка 16 килобайт. Это, конечно, уже не приведёт к такому впечатляющему результату, но всё равно будет приятно и полезно.

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

Функционал: сегодня и завтра.

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

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

За восемь с небольшим лет в ведомство поступило и рассмотрено более 315 тыс. сообщений о детской порнографии, почти 643 тыс. о незаконном обороте наркотиков, 211,5 тыс. о призывах к самоубийству, около 1,5 млн о нелегальных азартных играх.

В мобильном приложении помимо подачи жалобы на запрещенный контент также можно будет:

• отследить этапы ее рассмотрения;

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

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

По словам одного из создателей проекта, руководителя подразделения проведения экспериментальных работ Научно-технического центра ФГУП Главный радиочастотный центр (ГРЧЦ) Владислава Минакова, в ближайшее время будут расширены опции приложения:

• расширение функционала в части реализации кабинета СМИ и вещателя;

• введение новых групп пользователей (учредители СМИ, вещатели, главные редакторы);

• реализация возможностей оперативного получения используемой в деятельности СМИ информации;

• расширение способов доставки до поднадзорных лиц юридически значимых документов.

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

Увеличение функциональных возможностей приложения будет основано не только в связи с новыми полномочиями подразделений РКН, но и на основании опыта подписчиков.
Обратная связь с ними сегодня осуществляется посредством отзывов в магазинахGoogle PlayиApp Store, а также по электронной почте ermp@grfc.ru.

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

1) адаптация интерфейса;

2) рассмотрение возможности по расширению способов авторизации (по номеру телефона, госуслуги Москвы mos.ru).

Пока доступ к сервису РКН осуществляется через Единую систему идентификации и аутентификации (портал Госуслуг) и не требует дополнительной регистрации.
Начавшееся в феврале бета-тестирование приложения будет проходить до возможного выявления и устранения проблем в его работе. Вероятно, стабильный релиз будет уже в марте, рассказал эксперт ГРЧЦ. Также он сообщил, что обновления сервиса выходят по мере необходимости. За период бета-тестирования было сделано несколько таких доработок приложения. Масштабные обновления же с новым функционалом планируются 1-2 раза в год.

Запуск такого мобильного ПО это один из элементов цифровой трансформации, которую РКН активно ведет, начиная с 2020 года, в соответствии с утвержденной в декабре 2020 года ведомственной стратегией.

Насколько защищена конфиденциальность.

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

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

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

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

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

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

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

• сервером Госуслуг (авторизация);

• сервером Firebase Cloud Messaging (для push-уведомлений;

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

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

Понятно, что любые сервисы аналитики нужны, когда все идет не слишком хорошо: если LTV/CAC > 10, аналитикой можно и не пользоваться. Ниже рассмотрим полезные сервисы для freemium приложений на iOS, которые пригодятся почти любой команде для разработки и продвижения приложения.

Привет, меня зовут Виталик, сейчас я основатель Adapty.io, а до этого был iOS разработчиком и дата саентистом. Я поделюсь своим опытом по работе с сервисами для мобильных приложений.

Подавляющее большинство мобильных приложений монетизируются через трафик, то есть, через закупку рекламы. По моей оценке, у большинства приложений нет сайта или веб-версии, да и платформа часто одна iOS. Если нет у компании нет доступа ксильному органическому ресурсу (SEO, блог и т.д.), то все, что доступно компаниям для контролируемого продвижения это App Store Optimization (ASO) и реклама.

Сервисы, которые пригодятся для разработки и продвижения, можно разделить на шесть категорий:

1. Атрибуция трафика. Поможет ответить на вопрос откуда (с какой рекламы) пришли пользователи и построить юнит-экономику.

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

3. Отправка пуш-уведомлений. Опционально email.

4. Подключение платежей (in-app purchases), сбор аналитики подписок и их роста. Подключить платежи на любой платформе это всегда тяжело, собрать данные и не ошибиться, это еще сложнее.

5. ASO-инструменты. Аналитика и оптимизация органического роста в App Store.

6. Крэшлитика. Аналитика крэшей приложения.

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

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

Атрибуция

Зачем нужна

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

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

Кого выбирать

На рынке есть несколько основных игроков, которые умеют атрибутировать Facebook: AppsFlyer (70% рынка), Adjust, Tenjin, Branch.

Сколько стоит

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

В целом, эта цена абсолютно адская в соотношении к предоставляемой полезности, поэтому с ростом объемов стоимость сервиса будет расти медленнее. Более того, вы обязаны будете заплатить даже если трафик не сконвертируется и не окупится, то есть по факту вы платите за установку. Такая стоимость может легко увеличить стоимость за установку (CPI) на 10%.

Вывод простой торгуйтесь, если хотите сэкономить.

Легко посчитать, сколько примерно будет стоить AppsFlyer. Предположим, вы покупаете трафик на $10 000 в месяц при стоимости установки $2 -> 5 000 атрибуций -> 5 000 * 0.06 = $300.

Отмечу, что если вы не получаете данных об атрибуции при выключенном доступе к IDFA, то вы не платите за атрибуцию. Я официально спросил AppsFlyer об этом и получил ответ Да, если у клиента включен LAT, мы не получаем IDFA/GAID и установка может уйти в органику. Но мы также попытаемся сделать атрибуцию через вероятностное моделирование. И если не получится, тогда уйдет в органику.

Продуктовая аналитика

Зачем нужна

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

Фактически, любая система аналитики состоит из двух частей:

1. Хранилище данных. Сюда попадают сырые события о действиях пользователя.

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

Кого выбирать

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

Свой стек традиционно собирают на реляционной колоночной базе данных, например, Clickhouse + Tableau для BI. Дополнительно для сбора данных я рекомендую использовать Cube.js. В качестве слов для гугления накидаю: AWS Lambda, Redash, Google Big Query, Serverless.

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

Из сервисный решений традиционно выделяют Amplitude и Mixpanel. Дополнительно сюда можно добавить App Metrica и Firebase Analytics (Google Аналитика для мобильных устройств).

Традиционно выбирают несколько аналитик, чтобы сравнить точность. Обычно берут бесплатную и платную.

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

Который в дальнейшем добавляется в приложение и тестируется.

Сколько стоит

Стоимость своей реализации посчитать сложно. За оценку возьмите работу трех человек в течение 4-6 месяцев.

Прикинем для сервисов:

• App Metrica и Firebase Analytics бесплатные.

• Amplitude бесплатно до 10 миллионов событий в месяц.

• Mixpanel бесплатно до 100 тысяч уникальных пользователей в месяц.

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

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

По моему опыту, обычно платный план начинается с $2000 в месяц.

Отправка пуш-уведомлений

Зачем нужна

У отправки пуш-уведомлений бывает две цели:

1. Продуктовая. Например, вы получили уведомление о том, что такси уже приехало.

2. Маркетинговая. Когда вы пытаетесь что-то (до)продать пользователю.

Более того, пуши можно разделить по:

1. Триггерные и вызванные руками.

2. Таргетированные или не таргетированные.

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

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

Кого выбирать

Как и в сервисах аналитики, тут есть вариант сделать свое решение, либо использовать сервисы. И то, и другое так или иначе работает через APNS (Apple Push Notifications Service).

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

Обычная схема использовать провайдера для рассылки пушей и обращаться к нему со своего сервера через удобный SDK/API. Как пример таких сервисов AWS SNS и Firebase Cloud Messaging. В FCM есть общая система с Android и аналитика по отправке и доставке, это приятное дополнение.

Самая готовая и хорошая система отправки пушей позволяет строить кампании рассылок, где вы указываете цепочки пушей, триггеры, задержки отправок, аудитории и тд. Это сложные и не дешевые системы, такие как Intercom, Push Woosh, OneSignal. Они поддерживают не только пуши, но также email, in-app сообщения и многое другое.

Сколько стоит

Firebase Cloud Messaging бесплатно.

AWS SNS один миллион бесплатно, дальше $0.5 за 1 миллион.

OneSignal сколько угодно сообщений, но 10 тысяч подписчиков.

Цена растет быстро и странно, поэтому если у вас 100К и больше MAU, я бы готовился к ценнику от $1 000 в месяц

ASO

Зачем нужно

ASO (App Store Optimization) аналог SEO, только для приложений, когда пользователь ищет что-то в поиске в App Store/Google Play. С помощью ASO можно:

• Отслеживать ранжирование по ключевым словам

• Отслеживать конкурентов

• Прокачивать ранкинг, в том числе для локализации

И другие смежные задачи.

Есть гайдлайны Apple для улучшения ранкинга. В целом, оптимизация ASO и SEO это похожие вещи, которыми надо заниматься постоянно. Можно найти гайды и рекомендации, они есть в открытом доступе.

Кого выбирать

Я даже близко не эксперт в ASO, но знаю хорошие отзывы про AppFollow и AsoDesk. Как вариант, можно написать самописное решение на GitHub много библиотек, которые помогут с этим, например, здесь.

Сколько стоит

Сервисы стоят плюс-минус одинаково, я бы целился в несколько сотен долларов в месяц для небольшого приложения.

Подключение платежей и подписок

Зачем нужно

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

• Корректно валидировать и проводить покупку. Поддерживать восстановление.

• Привязывать покупку к пользователю.

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

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

Кого выбирать

По аналогии с аналитикой, тут есть два варианта:

1. Сделать самому.

2. Взять сервис.

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

Количество сервисов за последний год резко выросло. Среди них Adapty, AppHud, RevenueCat, Qonversion, Purchasely и если я подумаю, то еще парочку точно найду. Все сервисы объединяет базовое решение задач разработки, но некоторые ушли далеко вперед по маркетинговым фичам. Как показывает практика, техническая проблема проведения платежей самая простая во всей этой истории. Гораздо сложнее все корректно измерять и проводить A/B тесты платежных экранов.

Сколько стоит

В целом, все сервисы имеют похожую систему ценообразования: это фикс с порогом выручки, которая проходит через SDK + какой-то процент от выручки свыше определенного порога (около 0.05%). Для среднего приложения на объемах $50 000 в месяц можно ориентироваться на $250 долларов.

Разработка своей системы, в зависимости от сложности, у команды в 3-4 человека может легко занять 4-6 месяцев.

Крэшлитика (аналитика крэшей приложения).

Зачем нужно

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

Кого выбирать

AppMetrica

Firebase де-факто стандарт.

Выбирайте любой.

Сколько стоит

Бесплатно.

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

Я пишу про новости из мира мобильной разработки и маркетинга в канале Apple Developer News в Телеграм.

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

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

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

То есть, в строчках у нас когорты (группа) пользователей, которые установили приложение в определенный месяц, а в столбцах значения метрик по каждому месяцу с месяца установки (этот месяц первый или М1). В выделенной строчке М1 это январь, М2 февраль и тд. Каждый месяц количество подписчиков в данной когорте не возрастает, даже если пользователь установил в январе, а подписался в феврале, то он будет отнесен в когорту января. Нам кажется такой способ правильным для оценки сходимости.

Идея оценивать экономику так кроется в том, как работает привлечение пользователей. При закупке рекламы разработчик так или иначе платит за установки, а не за целевые действия. Даже в CPA кампания, все будет связано со стоимостью установки (CPI). Следовательно, чтобы оценить эффективность закупки трафика надо смотреть как именно люди установившие приложение в этот период будут монетизироваться. При этом, если пользователь установил приложение, но месяц не платил, он попадет только в М2.

Видим, что когорта пользователей января принесла нам суммарно до текущего момента времени $2900 выручки от 73 подписчиков.

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

Сойдется ли экономика?

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

Посмотрим внимательно на динамику подписчиков когорты января.

На текущий момент приложение заработало $2900 до комиссии Apple, или $2465 после вычета 15% (приложение находится в программе Apple для SMB). Также будем считать, что мы продаем недельные подписки в среднем по $10.

Мы видим, что количество активных подписчиков после первого месяца упало почти в 2 раза, дальше на 20%, потом всего на 10% до 24. Так как на момент написания заметок месяц еще не кончился, возьмем лучший сценарий пусть все 24 подписчика будут с нами всегда. И даже пусть они в среднем платят $15.48 дальше, то есть их ARPPU не меняется.

Чтобы добить до $4000 нужно чтобы подписчики заплатили больше $1500, даже при сохранении выручки за месяц в $372 и нулевой отписке, когорта сойдется в лучшем случае через 4-5 месяцев непрерывных платежей. На практике, учитывая предыдущую динамику, и зная, что трафик закупается равномерно, когорта вряд ли сойдется меньше, чем за пару лет, а по факту скорее всего будет в убыток. Причина такая, что недельные подписки постоянно напоминают о себе и пользователи реже остаются в долгосрочных платежах, ведь если приложение хорошее, гораздо выгоднее купить год. Но даже с подписками на месяц при такой динамики на вряд ли стоит ожидать положительной прибыли.

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