Мысли и рекомендации по созданию ориентированных на клиента и понятных данных.
Недавно, когда я слушал Data Science, особо выделялась фраза: данные - это абстракция реальной жизни, созданная людьми. Связи в данных не обязательно представляют ассоциации в реальной жизни . Идея заключалась в том, что данные не появляются сами по себе - скорее, люди конструируют данные для записи информации, имеющей значение в реальной жизни, и при этом непреднамеренно наполняют ее своими собственными мыслями. , предположения и предубеждения. Это может иметь последствия для понимания, которое мы извлекаем из данных.
Ведущий инженер в моей команде описал эту концепцию аналогично: записи данных похожи на чеки, напечатанные в старомодных точках продаж. Они заполняют формулу информации, которую кто-то запросил, а затем генерируются как побочные продукты реальных событий.
Это было просто в мире баз данных, управляемом транзакциями. Транзакции прекрасно соответствуют шаблонному захвату. То, что нижестоящие потребители данных хотели знать о транзакциях, было относительно неизменным: когда и где это произошло? Что было совершено и на какую сумму?
Некоторая сложность была внесена вместе с технологией обработки данных, управляемой событиями. Сообщение было отправлено клиенту на основе набора критериев, соответствующих его случаю. Что имеет значение в этом мероприятии? Фактическое содержание (текст и изображения) или просто однажды удаленная сводка метаданных: название сообщения («Вам также может понравиться»), идентификатор получателя и временная метка? Ответ зависит от предполагаемого использования данных (аналитическое / экспериментальное / нормативное), метода и задержки обработки, а также изменчивости контента. Нет смысла сохранять весь текст в виде резюме в механизме управления состоянием, но его запись может иметь аналитическую ценность, если клиент поделится сообщением публично со своими собственными комментариями.
Но настоящая сложность начинает раскрываться сейчас, когда данные выходят за рамки событийно-ориентированного мира, в котором они должны представлять реальные сущности целостным образом: например, клиентов, книги или опыт. Возможность идентифицировать одну сущность (например, клиента) по разным базам данных эффективным и семантически согласованным способом теперь является основным ожиданием потребителей данных. Алгоритм машинного обучения требует входных данных, которые аккуратно упакованы в виде хранилища сущностей и всех их атрибутов, известных как функции, что позволяет ему перебирать данные, находить закономерности и делать прогнозы.
Что происходит с шаблонами, когда сами входные данные смещены? Например, клиент A нажимает на страницу сведений о продукте, а клиент B нажимает кнопку быстрого просмотра для того же продукта. Разработчик данных решил зафиксировать оба этих события как «просмотр продукта», предполагая, что покупатель имел намерение просмотреть / совершить покупку в обоих случаях. Нюансы между различными событиями не регистрируются - аналитики, расположенные ниже по потоку, не могут различить воронку конверсии обоих продуктов, и алгоритм потеряет эти входные данные. Тем не менее, человек интуитивно понимает разницу: подробный обзор сигнализирует о большем интересе, чем быстрый просмотр.
Создаваемые нами данные должны отражать реальность (в той мере, в какой мы можем это сделать, учитывая, что мы по своей природе предвзятые существа, живущие в субъективных реальностях, чьи мозги заперты в темных черепах и никогда не могут напрямую воспринимать мир, вместо этого полагаясь на иногда - ошибочные данные наших органов чувств. Но давайте не будем останавливаться на платоновской пещере.) Кто определяет намерения клиентов, когда они действуют - и как это должно отражаться в абстракции, которую мы создаем для этого действия?
Вот несколько передовых практик, которые я собрал во время разработки данных для нескольких продуктов, ориентированных на потребителя:
- Фиксируйте факты, не предписывая толкования
Человек арендует машину в каршеринговом сервисе на 8 часов и водит на ней 3 минуты 07 секунд. Это факт, который нужно уловить. Вы можете интерпретировать такое поведение как «неудачный» опыт, но такая интерпретация должна произойти позже, когда вы будете строить и развивать несколько тезисов. Алгоритм может просеивать и идентифицировать этого пользователя как человека, который просто ценит удобство, а не стоимость - оставьте этот вариант открытым, устраняя неоднозначность своих предположений на основе захвата.
2. Забросьте широкую сеть.
Один из рецептов, который следует убрать из вашего дизайна данных, - это выдвижение «высокоценных» действий. События - это просто события, клиенты - это просто люди: пока не имеет значения, какие действия ваша компания хочет предпринять. Позвольте полученному массиву данных выявить действия, которые предсказывают конверсию, удержание или что-то еще, что вы цените в ходе анализа. Сосредоточение внимания на HVA может привести к снижению приоритета других событий, которые вы считаете менее ценными - вы можете легко ограничить свой анализ с помощью этого подхода.
3. Сохраняйте впечатления, а не поверхность.
"Buy Now CTA" - не лучшее название для точки данных. Клиент не использовал призыв к действию «Купить сейчас». Клиент купил. Ваши данные должны отражать то, что произошло, а не компонент продукта, с которым это произошло. Это позволяет избежать пузырей племенных знаний (необходимость знать названия всех возможных поверхностных элементов, чтобы построить воронку поведения) и заставляет вас рассказывать ту же историю с вашими данными, которую рассказал бы клиент, если бы он позвонил в службу поддержки или к сказанному другу об их опыте работы с вашим продуктом.
Несмотря на то, что я написал эти прекрасные правила, я часто ловлю себя на том, что нарушаю их. Предвзятости действительно трудно избежать, когда ты человек. Если у вас есть советы или идеи из вашего собственного опыта в области сбора данных, я хотел бы услышать о них в комментариях.
