Создание безопасных открытых реферальных систем: использование HashMaps для эффективного предотвращения мошенничества
22 августа 2023 г.Сарафанное радио — эффективный способ побудить людей к какой-либо деятельности. Это одна из самых эффективных стратегий для быстрого приобретения и потери клиентов или пользователей.
Компании стремятся расширить свою клиентскую базу и снизить текучесть клиентов. Эта цель привела к исследованию различных стратегий. Одним из известных подходов является реклама через различные каналы, как онлайн, так и офлайн, что сильно влияет на то, что люди рассматривают предлагаемые продукты или услуги. Другой метод, с которым я столкнулся, — это использование стимулов. Это включает в себя создание ценности для отдельных лиц, мотивацию их участия в рекламе из уст в уста и, в конечном счете, привлечение новых потенциальных клиентов и пользователей.
Слово, которое легко передает приведенное выше маркетинговое послание, — это реферальные системы, и, создав несколько реферальных маркетинговых кампаний на основе кода, я полагаю, что есть два типа рефералов, которые я считаю «открытыми» и < strong>«Закрытые» реферальные системы.
Закрытая реферальная система
Сам термин подразумевает чувство контроля, когда информация передается и KYC (Знай своего клиента) выполняется для вновь полученного лида. Как только лид завершает этот процесс, реферер получает поощрение. Закрытая система позволяет предотвратить неправильное использование и сохранить контроль.
Открытая реферальная система
Вы можете рассматривать их как открытый сезон. Доступ не ограничивается, а показатель конверсии в этом случае в основном заставляет людей переходить на страницу в надежде, что страница обеспечивает конверсию или может побудить людей выполнить задачу без запроса.
Достаточно моей мелкой маркетинговой информации отсюда. С инженерной точки зрения закрытая реферальная система, кажется, предлагает больше контроля и предполагает, что игры можно предотвратить или контролировать. Хотя я согласен, что приведенная ниже инженерная часть укрепит закрытую систему.
<цитата>Наконец-то немного инженерии.
Здесь я представлю пользовательскую историю, где ваша реализация будет зависеть исключительно от вас.
Открытая реферальная кампания — история пользователя
В предпродажной кампании партнерская ссылка продукта используется для демонстрации продукта потенциальным клиентам. Цель состоит в том, чтобы привлечь трафик, и каждый маркетолог, генерирующий трафик, получает право на получение публично согласованного поощрения, как указано в Условиях использования.
В этом случае мы будем продвигать Spotify и пытаться привлечь новых пользователей в Нигерии.
Я предполагаю, что мы реализовали этот код на предпочитаемых нами языках программирования. У нас есть прототип, и когда к серверу поступают запросы, мы направляем их к конечной цели, а также ведем наши внутренние записи.
Однако мы знаем о возможности неправомерного использования, когда, если кто-то использует одно и то же устройство для отправки запросов несколько раз, количество запросов соответственно увеличивается.
Иллюстрация
Итак, давайте предположим, что я пытаюсь заставить людей использовать Spotify таким образом, что если я получу 100 рефералов, моим стимулом будет бесплатный премиальный Spotify для семейного круга.
Да, имеет смысл использовать закрытую систему, когда новый лид присоединяется к Spotify, а реферер получает увеличение своего счета. Но давайте предположим, что это открытая реферальная кампания, я мог бы щелкнуть по своей ссылке 92 раза, чтобы получить интересующую меня оценку/статистику.
Показательный пример: мой счет увеличился до 9, потому что я нажал на ссылку.
Это создает проблему, как мы можем предотвратить игры?
Представляю вам кодировку-сериализацию и структуры данных. Я использовал хеш-карту в качестве источника правды, который отслеживает данные. он адаптируется ко всем случаям, поэтому позвольте мне объяснить причину использования хэш-карты.
<цитата>К вашему сведению: hashmap — это Dict в Python, Object в Js, Struct в Go и т. д.
Причиной моего решения является временная и пространственная сложность этой структуры данных: ключи уникальны, а значения расширяемы (податливы, это другая структура данных). Единственное, что может увеличиться, — это пространство данных, поиск осуществляется в постоянное время, то же самое и со вставками, что означает, что я могу искать, и если поиск неверен, я могу вставить.
https://gist.github.com/philipokiokio/62df7226e33d42ac1a0f6f05e1bf89a9?embedable=true Это из строки 33 приведенного выше текста. Таким образом, если Gaming_data пусто, это означает, что устройство, которое щелкнуло по ссылке, является уникальным посетителем, и поэтому щелчок считается законным, а не игрой. Мы можем увеличить количество баллов, а также предоставить конечный URL-адрес, если он есть, иначе URL-адрес будет строкой длины 0, указанной в строке 4. Здесь возможны два случая.
1. Интересующих данных нет в словаре, а затем мы присваиваем данные в словаре. 2. Данные существуют в словаре, но в значении (которое также является словарем) интересующее значение.
(link_code) не существует. В этом случае мы добавляем данные к значению. Обратное — когда он существует, в этом случае мы получаем URL-адрес и возвращаем его.
Эта функция просто манипулирует данными, за пределами этой функции есть несколько вещей, которые можно/нужно сделать. Обновление записи в БД на основе того, что длина URL составляет > 0. Другой способ выполнить следующий оператор: если длина URL-адреса равна 0, выдать HTTPException, если это условие не выполняется, обновить оценку записи и вернуть URL-адрес.
Для этой реализации требуется процесс, чтобы закрыть его, первое, что нужно сделать, это закодировать dict в строковый формат. Вот пример ниже:
Я использовал пакет на Python под названием ItsDangerous, чтобы преобразовать словарь games_data в строку, которая декодируется обратно в структура данных его ввода.
Теперь мы завершили часть этого решения, связанную с серверной частью, наша система должна ожидать, что этот игровой токен будет отправлен с запросом со стороны клиента на серверную часть. Поэтому я оставлю то, как вы прикрепляете данные, на ваше усмотрение, есть множество решений, которые можно принять, запросить параметры или заголовки.
Frontend/Clientside является привратником этой реализации, чтобы объяснить, что происходит, позвольте мне показать вам ответ сейчас с этой реализацией.
В этом ответе мы возвращаем URL-адрес и токен на стороне клиента. Клиентская сторона может помочь нам сохранить этот токен на устройстве того, кто нажимает на нашу ссылку. Реализация запроса от внешнего интерфейса к серверной части должна проверять наличие этого токена. Если этот токен существует, мы затем включаем его в любой метод, который мы решим. Таким образом, согласно приведенному выше запросу число должно было увеличиться до 10.
Вот как я указал, что токен должен быть отправлен обратно в мою систему.
Если мы проверим оценку владельца ссылки, она должна остановиться на 10 и не увеличиваться (скрестим пальцы).
Счет заморожен. Следует отметить, что мы всегда предоставляем токен независимо от данных в нем, поэтому мы можем постоянно менять токен.
Выше показано, как я разработал систему предотвращения мошенничества, которая включает в себя тяжелую работу с серверной частью и синхронизацию с интерфейсом.
Существует потенциальный способ сохранить эти данные в серверной части. Недавно я пытался изучить пользовательские агенты, но только что узнал, что пользовательский агент можно подделать, поэтому я ищу надежный способ идентификации устройств.
Если это возможно, мы можем сохранить этот токен в таблице, а идентификатор можно сохранить в таблице устройств, а для связи между ними можно использовать external_keys или любой другой метод, который вы предпочитаете.
Система мошенничества, наложенная на закрытую реферальную систему, снижает шансы на игру, и даже мое предложение выше может быть реализовано, тем более что мы знаем первичный ключ каждого пользователя, реферера и нового лида.
До следующего раза, мир! :::информация
Также опубликовано здесь :::Еще предикация
Если предикация
Оригинал