пушить что это значит в программировании
Git для начинающих. Урок 6.
git push и git pull
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Во втором уроке мы создавали репозитории на github и научились клонировать их. После этого мы работали только с локальным репозиторием, на своей машине. Сегодня мы рассмотрим взаимодействие с удаленным репозиторием.
Что такое push (пуш)
Зачем пушить на сервер
Когда пушить на сервер
Когда сделали новый коммит или несколько коммитов
Как узнать, что есть незапушенные коммиты
В командной строке набрать git status
Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов. Если незапушенных коммитов нет, то картина будет такая
«is up-to-date» означает, что у нас нет незапушенных коммитов
master и origin/master
git push в терминале
Как пушить в PhpStorm
Что такое pull (пулл)
Это скачивание данных с сервера. Похоже на клонирование репозитория, но с той разницей, что скачиваются не все коммиты, а только новые.
Зачем пулиться с сервера
Чтобы получать изменения от ваших коллег. Или от себя самого, если работаете на разных машинах
git pull в терминале
Как пулить в PhpStorm
Когда что-то пошло не так.
Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры
git push rejected
Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое
Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?
Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера. Те самые, которые успели сделать наши коллеги. То есть сделать git pull.
Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git». Это так называемый мердж-коммит, о нем чуть ниже.
Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.
Как избавиться от мердж-коммита
Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.
При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.
Мердж-коммит в PhpStorm
PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.
Что могу посоветовать
Если мы работаем в одиночку, то удаленный репозиторий нужен только для сохранения резевной копии. Скорее всего, мы будем в него только пушить.
Но при работе в команде имеет смысл подумать над такими вещами:
Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут. Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.
В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.
Понимаем сленг программистов: мини-словарь для начинающих разработчиков
Начинающие разработчики не сразу понимают старших товарищей. Фразы вроде «я апишку свитчнул» или «заимпорти другую либу» звучат для новичков как лекция по математическому анализу для первобытного человека. Поэтому мы решили сделать небольшой словарь профессионального сленга программистов.
Слова и фразы в словаре отсортированы по алфавиту. Кстати, словарь можно дополнять. Пиши в комментариях термины, с которыми вы сталкивались на работе.
Аджайл — от англ. Agile. Общий термин, описывает ценности и принципы гибкой разработки программного обеспечения, а также практические подходы к разработке. Понятие Agile стало популярным после публикации Манифеста гибкой разработки программного обеспечения в 2001 году.
Айдишник — id, идентификатор.
Альфа — этап разработки программного обеспечения, на котором разработчики добавляют в программу новые функции, а тестировщики испытывают программу. Это внутренний или непубличный этап.
Апишка — API, программный интерфейс приложения или интерфейс прикладного программирования.
Аутсорс — аутсорсинг, передача компанией части операционной деятельности другой компании.
Адаптив — адаптивный дизайн, адаптация интерфейса к использованию на разных экранах.
Баг — от англ. Bug — жучок, клоп. Ошибка в программе.
Бахнуть — что-то быстро сделать, изменить или дополнить функциональность приложения.
Бета — бета-версия, приложение на стадии публичного тестирования.
Бот — сокращение от «робот». Ботом называют программу, которая автоматизирует интерфейс. Пример — автоответчик в чате.
Бэкенд — от англ. Back-end. Программно-аппаратная или серверная часть приложения.
Бэкап, бэкапить — резервная копия или процесс создания резервной копии приложения.
Ворнинг — от англ. Warning — предупреждение. Предупреждающее сообщение в интерфейсе.
Войтивайти — шуточное, обозначает процесс переквалификации далёкого от сферы IT специалиста в разработчика.
Выкатить — сделать доступным для пользователей. Например, «выкатили новую версию сайта» значит сделали новую версию сайта доступной для пользователей.
Выпадашка — выпадающее меню, то же, что и «дропдаун».
Галера — компания, в которой платят низкие зарплаты и не ценят разработчиков.
Гит — система контроля версий Git или сервис GitHub.
Г****окод — плохой, некачественный код. Объяснение термина есть в статье нашего студента.
Градиент — плавный переход из одного цвета в другой.
Движок — в веб-разработке так называют системы управления контентом.
Дебажить — устранять ошибки, баги.
Деплой, деплоить — развёртывание, публикация рабочей версии приложения. Пример: задеплоить сайт — перенести сайт с тестового на рабочий сервер, сделать его доступным для пользователей.
Джун, джуниор — от англ. Junior. Младший разработчик. Специалист без опыта или с минимальным опытом работы.
Дезигнер — презрительно-снисходительное название дизайнера.
Драй — от англ DRY, don’t repeat yourself. Принцип программирования, предлагающий избегать повторений кода.
Дропдаун — выпадающее меню, то же, что и «выпадашка».
Жаба — язык программирования Java.
Жабаскрипт — язык программирования JavaScript.
Залить — загрузить. Например, «залить файлы на сервер».
Запилить — сделать что-то, добавить какую-то функциональность.
Змея — язык программирования Python.
Исходник — файлы, в которых находится исходный код приложения, или сам исходный код.
Итерация — повторение. «Мы сделали несколько итераций» — мы повторили шаг несколько раз.
Коммит, коммитить — от англ. To commit — совершать. В контексте работы над приложением — сохранять код в репозитории.
Костыль — код, который нужен, чтобы исправить несовершенство ранее написанного кода.
Это интересно На Хекслете есть раздел с бесплатными курсами. Здесь есть курсы по логике, английскому языку, операционным системам, по языкам и инструментам программирования. Регистрируйтесь и учитесь бесплатно!
Либа — от англ. Library — библиотека. Речь идет о библиотеках кода, например, React.
Линтер — общее нарицательное название программ, которые анализируют код и предупреждают разработчика об ошибках.
Лист — от англ. List — список.
Локалка — локальный. Например, локальный сервер или сеть.
Мидл — от англ. Middle — средний. Уровень разработчика, следующий за джуниором. Опыт и уровень знаний миддла позволяет ему самостоятельно решать серьезные задачи.
Мёржить — от англ. Merge, сливать. Речь идет об объединении или слиянии веток кода.
Меншить — от англ. Mention — упоминание. Речь идёт об упоминаниях в чатах или соцсетях. «Менши меня, когда будет готово» значит «упомяни меня, когда будет готово».
Навбар — навигационный блок на сайте или в интерфейсе программы.
Накатить — внести изменения, задеплоить новую версию приложения. Противоположное термину «откатить».
Откатить — удалить изменения, вернуть предыдущую версию приложения. Противоположное термину «накатить».
Ось — операционная система.
Падаван — ироничное название стажёра или джуниора.
Пилот — пробная (пилотная) версия продукта.
Питон — язык программирования Python.
Подвал — то же, что и «футер». Элемент структуры страницы, который находится в нижней части и содержит служебную информацию.
Поплыла вёрстка — некорректное отображение страницы в браузере.
Продакшн или продакшен (продакшн-код) — обозначение кода для рабочей версии приложения.
Пушить — использовать команду push, публиковать что-то.
Пэхапэ — язык программирования PHP, то же, что и «пыха».
Пыха — язык программирования PHP, то же, что и «пэхапэ».
Релиз — программное обеспечение на стадии публичного использования. Стабильная версия программы, которая прошла тестирование.
Рекурсия — описание процесса с помощью самого процесса. Например, выражение «рекурсивный вызов функции» описывает ситуацию, в которой функция вызывает сама себя.
Репа — репозиторий, хранилище данных. Например, код программы можно хранить в репозитории на GitHub.
Ридми — файл Readme, в котором содержится информация о программе.
Ругаться, например, линтер ругается — сообщения об ошибках в коде, работе сервиса и так далее.
Сабж — от английского Subject — тема, предмет. «По сабжу» — по теме обсуждения.
Свитчнуть, свичнуть — переключить. От английского switch.
Сетка — модульная сетка, используется для дизайна и вёрстки страниц.
Сеньор, синьор — от англ. Senior — старший разработчик.
Стек — изначально абстрактный тип данных. В разговорной речи используется для обозначения списка технологий, которые использует разработчик или компания. Пример: «Наш стек — HTML/CSS, JavaScript, React».
Софт — от англ. Software — программное обеспечение.
Софт-скилы — от англ. Soft skills — знания и качества специалиста, прямо не связанные с профессиональной деятельностью. Примеры: коммуникабельность, проактивность.
Темплейт — от английского template — шаблон.
Тестировщик — специалист по тестированию программного обеспечения.
Тимлид — от английского Team leader — руководитель команды. Координатор группы программистов.
Убить — удалить что-то. Например, «убить профиль» означает удалить профиль.
Фидбек — от англ. Feedback — обратная связь.
Фича — функция, возможность. От англ. Feature.
Фреймворк — от англ. Framework — каркас. Инструмент разработки, набор типовых шаблонных решений, упрощающих работу программиста. Примеры: Laravel, Bootstrap.
Фронтенд — от англ. Front-end — клиентская часть приложения.
Хатэмээль, хатээмэль — HTML, язык гипертекстовой разметки.
Хардкодить — статически прописывать в коде данные, которые должны вычисляться динамически. Плохая практика, антипаттерн в программировании.
Хацкер, кулхацкер — ироничное название начинающего специалиста, который считает себя опытным программистом. От английского hacker и cool hacker.
Хедер, хэдер — элемент структуры веб-страницы, находится в верхней части и содержит логотип, меню, служебную информацию.
Цэмээс, цээмэс — от англ. CMS — content management system, система управления контентом.
Цээсэс — от англ. CSS — Cascading Style Sheets, каскадные таблицы стилей.
Юзать — от английского to use — использовать.
Ява — язык программирования Java.
Яваскрипт — язык программирования JavaScript.
ЯП — язык программирования.
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Способы взаимодействия сервисов друг с другом. Пулинг/пуш. Достоинства/недостатки. Выбор
Курьер доставил заказ. По смене статуса заказа надо уведомить заинтересованные стороны об этих событиях.
Клиент отправляет сообщение в чат поддержки. Нужно уведомить сервисы поддержки о поступивших данных от клиента.
Построение отчёта завершено. Ожидающий отчёт пользователь может его загрузить. Надо его уведомить об этом.
Знакомые/типовые ситуации. Одному сервису надо уведомить другой (другие) о происшедших событиях.
Давайте немного усложним:
Какие способы уведомления есть?
Активность со стороны сервера
Это, в общем-то, типовое решение. Сервер держит список заинтересованных сторон. По мере появления событий выполняет HTTP-запросы к клиентам.
Подвариант этого решения: Websocket. Сервер отправляет события в сокеты всем подписанным сторонам.
Повторы, обработка ошибок
Рано или поздно любой TCP/HTTP-канал сталкивается с недоступностью другой стороны. Что делать после возникновения ошибки? Повторять запросы? Что делать с вновь поступающими запросами? Ждать, пока успешно выполнятся предыдущие?
Рассмотрим виды ошибок:
Получив неустранимую ошибку, клиент может только записать её в лог. То есть, если полная остановка доставки сообщений не приемлема, то, получив неустранимую ошибку, типовым решением будет считать, что «уведомление доставлено», и переходить к доставке следующих уведомлений. Вероятно, это единственный нормальный путь.
Идя по этому пути, надо постоянно и внимательно следить за мониторами таких ошибок. Анализировать трафик на тему «почему возникла неустранимая ошибка?» и «можно ли жить дальше с этой ошибкой».
Но это не самая большая проблема.
Более интересными являются проблемы:
500-е ошибки
Мы выполняем запрос-передачу данных для сервера X. Происходит 500-я ошибка. Что это?
Возможны два варианта:
Сервис-приёмник данных по какой-то причине именно сейчас не работает (перегружается, переключается БД итп). В этом случае повтор запроса в дальнейшем приведёт нас к успеху.
В сервисе допущена ошибка, приводящая к 500. В этом случае, сколько бы повторов мы ни сделали, до исправления кода в приёмнике ситуация не изменится.
То есть, по повторяемости запросов ошибки у нас делятся на три вида:
Те, которым повтор поможет (сетевые, устранимые 500-ки).
Те, которым повтор не поможет, но выглядят как те, которым поможет (неустранимые 500-ки).
Те, которым повтор не поможет (например 40x-ки).
Разрабатывая политику повторов, помимо указанной проблемы, имеем ещё множество других проблем:
Как часто повторять запросы?
Не будем ли мы «укладывать» внешний сервис, повторяя запросы?
Не будем ли сами «укладываться», если одна из внешних систем по какой-то причине имеет некорректный TCP-стек ( iptables DROP )?
Если посмотреть на систему повторов запросов, то обнаружится, что практически в каждом случае она выбирается индивидуально.
Если сервис, генерирующий событие, и занимается доставкой его до заинтересованных сторон, то имеем
минимальный лаг доставки
минимальная нагрузка на хранилище сообщений;
необходимость повторов в случае неуспеха доставок
необходимость ведения реестра, кому что доставлено и кому что нужно доставить
двусмысленность некоторых ошибок: непонятно, можно (нужно) ли повторять, или нет
система повторов может быть причиной DDoS для клиентских сервисов.
Также есть некоторое количество организационных минусов:
После того, как клиент прекратил де-факто работу (тут два варианта: сервера выключены, сервера не выключены), система продолжает доставлять ему уведомления.
Вебсокет в режиме клиент-сервер
Часть описанных проблем решает постоянное соединение, инициируемое клиентом. Однако именно часть.
Пулинг
Достоинства пулинга
Максимально быстрое восстановление работоспособности после факапов.
Недостатки пулинга
минимальный лаг доставки сообщений равен интервалу пулинга, который обычно выбирается ненулевым
множество сервисов пулящих один создают существенно бОльшую нагрузку, нежели случай с активным сервисом. Сервисы, для которых нет сейчас никаких сообщений, всё равно создают нагрузку на подсистему доставки сообщений.
Ещё один неочевидный, организационный недостаток пулинга: часто способ получения новой порции данных связан со структурой хранения данных.
отсутствие двусмысленности, описанной выше
наиболее быстрое восстановление работоспособности после сбоя
максимальная независимость от сетевого стека TCP на клиенте
нет необходимости хранить/майнтенить список клиентов.
Лаг доставки
Как правило, запросы для пулинга формулируются как «есть ли данные для меня; если есть, то какие?». Такие запросы (в случае, если они некорректно спроектированы) зачастую имеют следующие проблемы:
при перегрузках количество данных в ответе может расти, или время выполнения запроса ухудшаться.
В случае, если получение очередной порции данных сопровождается простой выборкой из BTREE индекса, то и ответ на вопрос «есть ли данные?», как правило, сравнительно бесплатен. Об индексах поговорим ниже.
А сейчас давайте рассмотрим алгоритм работы традиционного пулера.
Обрабатываем полученные данные
Пауза соответствующая интервалу
Если рассматривать этот алгоритм, то видим, что переменная index и есть то, что связывает нас со структурой хранения данных.
Такой алгоритм, как правило, используют новички и. приводят себя к трудноустранимой проблеме: запросы с большими значениями index сделать индексируемыми крайне сложно. Почти невозможно.
Почему разработчик попадает в такую ситуацию? Потому что проектирует БД и API отдельно друг от друга. А нужно посмотреть на все компоненты в целом и на влияние их друг на друга.
Проблема состоит в том, что в БД, как правило, данные хранятся в виде плоских таблиц. Когда мы получаем очередную порцию данных с одними и теми же условиями фильтрации, то приходится делать что-то вроде следующего:
Как сделать план независящим от положения смещения? Использовать вместо смещения выборку из индекса:
Первичная инициализация. index := 0
Выполняем запрос limit данных, передавая в запрос index
Пауза, соответствующая интервалу
В системе с такой архитектурой, как правило, уже нет существенных препятствий к снижению интервала до минимальных значений (вплоть до нуля).
Но давайте ещё порефлексируем над архитектурой. Что плохого в ней?
Алгоритм привязан к структуре данных
Выполняется практически полностью на стороне клиента
Вследствие предыдущей проблемы сложно, например, централизованно модифицировать его на иную работу после факапов/проблем.
Пользователь может сам подставлять в index произвольные значения. Иногда это может быть нежелательно или приводить к багам, которые разработчику сервера сложно понять.
Давайте ещё раз модифицируем алгоритм. Заменим index на state и управлять им будем с сервера:
Выполняем запрос limit данных, передавая в запрос значение state
Что мы получили? Гибкость.
Переменная state определяется только сервером и не обязана быть привязанной к числу смещения. При желании в этой переменной можем хранить JSON со многими полями.
Если в переменной state хранится не только позиция окна, а, например, и значения фильтров и криптоподпись, то эту переменную имеет смысл называть курсором. Переименуем переменную ещё раз и избавимся от постоянных задержек:
Если данные были, перейти к шагу 2
Таким образом, получаем алгоритм, минимизирующий число запросов, если данных для клиента нет, и запрашивающий данные с максимальной производительностью, если таковые имеются.
Рекомендации по работе с курсорами:
Поскольку хранением курсора между запросами озадачен клиент, то имеет смысл хранить в курсоре и версию ПО сервера. В этом случае можно написать дополнительный код, обеспечивающий обратную совместимость (конвертацию форматов курсоров).
Во избежание трудных багов весь набор фильтров, полученных в первом запросе, хорошо хранить в курсоре и в последующих запросах игнорировать параметры фильтрации не из курсора. Перфекционисты могут даже выделить инициализацию курсора в отдельный запрос.
Во избежание введения в соблазн пользователей использовать в своём коде какие-то данные из курсора, лучше не использовать человекочитаемую строку в значении курсора. JSON, пропущенный через base64-кодирование (и криптоподписанный) подходит идеально.
Пример. Изменение алгоритма после сбоя.
Любая система гарантированной доставки сообщений из точки А в точку B в случае факапов будет накапливать пул недоставленных сообщений. После восстановления работоспособности будет период времени, когда приёмник данных сильно отстаёт от источника.
В случае, если порядок доставки сообщений возможно нарушать, то обработчик запроса с курсором может (продетектировав значительное отставание) начать возвращать два потока данных: тот, на который подписан клиент, и тот же, но с более актуальными данными.
Таким образом, пользователи, запросившие отчёт прямо во время факапа, продолжат его ждать (и дождутся). А пользователи, запросившие отчёт после факапа, получат его с небольшой задержкой.
Пример алгоритма серверной стороны, включающего второй поток в случае сильного отставания, приведён на рисунке.
Пофантазировав, схему можно дополнить не одним, а несколькими фолбеками.
Курсорная репликация
Описанные курсоры можно использовать для репликации данных с сервиса на сервис.
Часто один сервис должен иметь у себя кеш/реплику части данных другого сервиса. При этом требований синхронности к этой реплике нет. Поменялись данные в сервисе A. Они должны максимально быстро поменяться и в сервисе B.
Например, мы хотим реплицировать табицу пользователей с сервиса на сервис.
Для такой репликации можно использовать что-то готовое из инструментария баз данных, а можно сделать небольшой «велосипед». Предположим, что пользователи хранятся в БД PostgreSQL. Тогда делаем следующее:
модифицируем изменяющие пользователей запросы, чтобы на каждое изменение записи пользователя значение lsn устанавливалось бы из растущей последовательности
строим по полю lsn (уникальный) BTREE индекс.
В этом случае обновление записи пользователя будет выглядеть примерно так:
А запрос для работы курсора будет выглядеть как-то так:
Итоги
Почти во всех случаях, когда применяется активная система уведомлений зависимых сервисов, её можно заменить описанной курсорной подпиской.
При этом проблемы доступности клиентов, настроек, работоспособности TCP-стека останутся у клиентов
Максимально быстрое и простое восстановление после простоя/сбоев. Отсутствие двусмысленностей в кодах ошибок.
Основы успешной реализации push-уведомлений для мобильных приложений
Наши разработчики в Techmas часто сталкиваются с задачами создания уведомлений (push notifications). Несмотря на простоту и популярность технологии, в её реализации есть ряд особенностей, о которых и пойдёт речь в этой статье.
Push-сообщения могут стать великолепным маркетинговым инструментом, если они грамотно реализованы. Любое мобильное приложение или игра должны выполнять не только свои прямые функции, но и (даже в большей степени) так взаимодействовать с пользователями, чтобы последние с удовольствием возвращались в приложение и покупали дополнения к нему. К слову, по статистике сервиса Kahuna хорошо разработанные push-уведомления увеличили показатель возвратов пользователей в приложения более чем в 2 раза. Анализируемые периоды: 30, 60, 90 дней. Но прежде, чем говорить о грамотной реализации, посмотрим, как работают push-уведомления.
Общие сведения о технологии Push Notification
Push-уведомления – это такой способ распространения контента (системных сообщений), когда уведомления отправляются от сервера клиенту по инициативе сервера на основе определённых параметров. В отличие от обратной схемы «клиент-сервер» (Pull), push-технология выгодна тем, что даёт пользователю таргетированную информацию, которая может быть ему полезна, но об этой пользе он может пока не знать.
Изначально технология Push Notification имела отношение не к мобильным приложениям, а к сети PointCast, занимавшейся рассылкой новостей фондового рынка. Эту же систему давно используют суды США для рассылки подписчикам данных о процессах. Позже Microsoft и Netscape включили технологию в свои браузеры, но из-за низкой скорости подключения пользователей в то время она была вытеснена pull-технологией RSS. И лишь потом термин получил широкую известность после внедрения технологии компанией Google в ОС Android (Google Cloud Messaging, GCM) и компанией Apple в iOS 3 (Apple Push Notification Service, APNS). На примере последнего рассмотрим элементарную схему работы Push-уведомлений.
Схема работы Push Notification на примере сервиса APNS
Зачем нужны промежуточные сервисы
Существуют нюансы в рассылках push-уведомлений для разных мобильных платформ (Android, iOS, Windows Phone). Допустим, если приложение было удалено пользователем, то все сервисы сообщают о том, на какие устройства не следует больше отсылать уведомления. Осуществляется данный процесс посредством сообщения серверу токенов этих устройств. Однако если у GCM отсылка идентификаторов происходит сразу, то у APNS имеется специальный feedback server (сервер обратной связи), с которого список таких токенов забирается раз в сутки. Для рутинной работы с этими различиями и нужны промежуточные сервисы.
В случае разработки мобильного приложения с помощью какого-либо кроссплатформенного решения (к примеру, Appcelerator) такой промежуточный сервис, как правило, интегрирован в него. Допустим, в том же Appcelerator это Appcelerator Cloud Services (ACS), представляющий собой дополнительный сервис каналов уведомлений. Такой канал (channel) объединяет несколько устройств, являясь своеобразным идентификатором, состоящим из цифр и букв. ACS даёт возможность отправлять пуши и по токену устройств. Итак, данный промежуточный сервис берёт на себя функцию обновления информации об устройствах и взаимодействует с APNS и GCM.
Форма уведомления. Сразу выдавайте интересную информацию, лучше в заголовке. Одинаковые пуши вида «Новые распродажи в нашем магазине» не работают: дайте конкретику. Неплохо также использовать Deep Linking (указывать в сообщение внешние ссылки на конкретную страницу сайта).
Гибкая настройка. Чем более детальна настройка того, о чём именно в рамках вашего продукта хочет получать сообщение пользователь, тем лучшее. Персонализированные рассылки всегда имеют больший отклик. Позвольте пользователю настроить уведомления так, как ему интересно и удобно, с максимумом подробностей.
Интерес пользователя. Сообщайте пользователю о том, что он хочет услышать, а не о том, что вы хотите ему рассказать. Для этого нужно собирать информацию о том, что интересно пользователю. Простой пуш о новом ресторане от городского гида не сравнится с пушем о новом ресторане в том районе, где живёт пользователь с информацией об утренних скидках – ведь он часто завтракает в кафе. Аналитика и ещё раз аналитика.
Статистика. Её нужно собирать, чтобы понять: когда эффективней рассылать сообщения; какие типы уведомлений эффективней; насколько те, кто получают ваши пуши, чаще заходят в приложение, чем те, кто не подписан; сколько пользователей открыли приложение по тому или иному пушу; другие виды анализа поведения пользователей.
Тестирование. Используйте разные формы подписки, тексты уведомлений, время рассылки и общую push-стратегию. Следите за отзывами в сети – это даст вам богатую информацию о том, как улучшить рассылку.
Звук уведомлений. Настройте свой, неповторимый. Чтобы пользователь знал, что новое сообщение пришло именно от вашего приложения. Не делайте его раздражающим – сделайте комфортным.
Сервисы автоматизации Push-рассылки
Push Woosh. Выдаёт удобные и понятные отчёты, совместим со многими платформами, отлично сегментирует аудиторию по разным группам признаков.
Urban Airship. Осуществляет таргетинг и анализ аудитории, позволяет выбирать различные стратегии удержания пользователя и создавать уведомления расширенного формата.
Appsfire`s Appbooster. Бесплатный сервис со стандартным набором функций.
Parse Push. Позволяет собирать уникальные данные для аналитики, с лёгкостью интегрируется в любое приложение.
В заключение отметим, что push-уведомления, конечно, являют собой простой и эффективный способ возврата и удержания пользователя в частности и мощный маркетинговый инструмент в целом. Но это с точки зрения пользователя. Со стороны разработчика же существуют некоторые сложности. Реализация уведомлений сильно зависит от внешних вводных: изменения в OS или в промежуточном софте приводит к необходимости доработки приложения. Так, в Appcelerator появился новый инструмент Arrow Push, который пришел на смену ACS – и это лишь один из примеров. Более того, доставка пуша не гарантирована в принципе, а это поднимает вопрос о надёжности технологии Push Notification. Однако любая технология имеет свои плюсы и минусы, и что перевешивает в данном случае – вопрос открытый.