Программный кейс по созданию subscribe продукта

12.05.2018
Александр Михайленко
5 минут
subscribe проекты, Кейсы, Разработка,
215

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

Сегодня рассмотрим процесс создания subscribe продукта https://wowtouchbox.com/ , который успешно работает на beauty-рынке Украины.

Для начала определим список этапов, которые стоит сделать программисту при создании subscribe продукта:

  1. Выбор системы разработки и её обоснование.
  2. Выбор второстепенных технологий.
  3. Определение MVP модели продукта.
  4. Этапы реализации продукта.
  5. Тестирование продукта.

Выбор системы разработки и её обоснование

выбор системы разработки

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

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

 

В финале остались к рассмотрению две принципиально разных системы, на которых можно реализовать проект:

  • Laravel Framework;
  • WordPress CMS.

 

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

Сравнивая их, мы выделили 3 основных параметра, которые играли для компании существенную роль:

  1. Стоимость часа работы;
  2. Время, затраченное на проект;
  3. Гибкое управление и масштабируемость.

 

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

 

Время, затраченное на проект. Этот параметр был на самом деле самым спорным и субъективным при составлении ТЗ и выставлении сроков. Если сюда учитывать навыки разработчика и систему, на которой будет сделан продукт, у нас выходила очень большая разница между тем, чтобы сделать проект на фреймворке и получить мощнейший опыт в разработке и  тем, чтобы реализовать проект в максимально быстрые сроки на хорошо известном нам WordPress. В итоге был озвучен срок — 2 месяца.

 

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

 

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

 

Выбор второстепенных технологий

выбор второстепенных технологий

В данном пункте речь пойдет не о технологиях вида JQuery, Sass или Git, так как эти технологии уже вошли в «быт разработчика ». Здесь о сторонних библиотеках и сервисах API, которые были необходимы для такого комплексного продукта.  

 

Шлюз оплаты

 

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

 

И тут стал очень важный вопрос: «Как и где хранить данные о карте клиента?»

 

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

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

PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Стандарт разработан международными платежными системами Visa и MasterCard. Любая организация, планирующая принимать и обрабатывать данные банковских карт на своем сайте, должна соответствовать требованиям PCI DSS.  

 

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

Данный сертификат нужен как раз таки платежным системам либо полностью самостоятельным и большим проектам типа Amazon.

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

 

Выбираем платежную систему

 

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

Итак, в результате поисков и требований клиента, было найдено две платежные системы, которые были максимально безопасны и подходили по материальным условиям. Это API таких систем как LiqPay и Fondy.

В результате изучения документации API сервисов было принято решение делать интеграцию именно с сервисом Fondy. Так как он предоставлял более простой программный интерфейс для взаимодействия и довольно гибкие настройки на стороне самого мерчанта (сайта).

 

Важно! Что следует учитывать разработчику при работе с оплатой по токену?

 

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

 

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

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

 

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

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

 

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

На этом этапе больше сторонних сервисов не потребовалось и теперь можно приступить к обзору следующего этапа.



Определение MVP модели продукта

MVP модели продукта

MVP (Model-View-Presenter) — шаблон проектирования пользовательского интерфейса.

Безусловно, такие вещи как состав MVP, решаются владельцем продукта и Product менеджером. Но и Team Lead (или ведущий разработчик проекта) тоже имеет слово в этом этапе создания продукта. При определении минимального набора рабочего функционала и разработчик, и менеджер, и владелец должны максимально продуктивно взаимодействовать между собой, чтобы точно определить сроки реализации и возможные трудности.

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

  • Создание аккаунта клиента;
  • Выбор товара / услуги;
  • Возможность разовой оплаты/подписки.

Именно такой набор функционала должен обязательно быть в MVP модели subscribe продукта любого рода. Именно эти 3 составляющие создают ядро сайта и позволяют клиенту пользоваться вашими товарами и услугами.

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

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

Этапы реализации продукта

Этапы реализации продукта

На этом этапе максимально сотрудничают разработчики и Project менеджер. Так как именно эта команда задает весь ритм работы на проекте. В рамках создания WOW! TOUCH была применена технология ведения проектов scrum, что очень положительно сказалось на создании проекта, а также позволило сплотить команду вокруг единой цели.

 

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

 

Тестирование продукта

тестируем

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

В нашей работе было организовано 3 этапа тестирования.

Этап первый. Тестирование разработчиками

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

Этап второй. Тестирование внутри компании

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

Этап третий. Тестирование на закрытой группе людей

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

 

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

 

Получить 7 писем о том,
как улучшить свой AdWords аккаунт
+ PPC статьи

Имя
e-mail
Улучшить AdWords

Улучшить свой AdWords

Получите 7 писем, о том, как можно улучшить свой аккаунт в AdWords

Подписаться

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




В версии 2.2.0

  • Добавлена поддержка "Google Keyword Planner"
  • Используйте "LeftALT + S" для поиска слов
  • "Показать/скрыть" теперь полностью скрывает расширение с экрана

Основные комбинации

  • LeftMouseClick для добавления слова, повторное нажатие - для удаления
  • LeftALT + LeftMouseClick - для сбора фраз
  • LeftALT + S - для поиска слов