Как лучше всего считать уников и неуников для пп?

Тема в разделе "PHP", создана пользователем verfaa, 6 фев 2013.

Статус темы:
Закрыта.
Модераторы: latteo
  1. verfaa

    verfaa

    Регистр.:
    29 янв 2007
    Сообщения:
    371
    Симпатии:
    41
    Есть сайт, хочу попробовать сделать для него простую партнёрскую программу.
    Раньше такой функционал не реализовывал, поэтому первый вопрос, который у меня возник, каким образом лучше считать уников и неуников для своих партнёров?
    Как большинство партнёрок это реализуют?

    У меня по этому поводу такие мысли:
    К примеру юзер приходит по ссылке вида: http://site.com/tovar.php?pid=7496

    В файле tovar.php я напишу примерно такой код:

    Код:
     
    if isset($_GET["pid"]) {
     
        $pid = intval($_GET["pid"]);
     
        if(isset($_COOKIE['PartnerID'] && $_COOKIE['PartnerID'] == $pid) {
         
            // Add Raw
            mysql_query("INSERT INTO partners (pid, raws, date)
                                VALUES ('".$pid."', raws=(raws + 1), DATE()
                                ON DUPLICATE KEY UPDATE pid='".$pid."', raws=(raws + 1), DATE())");
         
        } else {
         
            setcookie ("PartnerID", $pid, time()+14400);
         
            // Add Raw + unique perehod
            mysql_query("INSERT INTO partners (pid, unique, raws, date)
                                VALUES ('".$pid."', unique=(unique+1), raws=(raws + 1), DATE()
                                ON DUPLICATE KEY UPDATE pid='".$pid."', unique=(unique+1), raws=(raws + 1), DATE())");
         
        }
     
    }
    


    Т.е. проверяем если передана $_GET["pid"], то выбираем её целочисленное значение.
    Далее если существует $_COOKIE['PartnerID'] и если $_COOKIE['PartnerID'] равна тому зачению которое к нам пришло, то просто добавляем 1 raw переход этому партнёру.

    А иначе если $_COOKIE['PartnerID'] не существует (но переменная $_GET["pid"] всётаки передана) то устанавливаем в браузер посетителя cookie PartnerID со значением которое к нам пришло. А партнеру добавляем 1 уник (unique переход) и 1 неуник (raw переход).

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

    И еще хотел бы спросить: как лучше всего организовать структуру базы данных mysql, чтобы удобно записывать в неё id вебмастеров, уники, неуники, заказы и даты. И главное потом выводить их партнеру в классическом для большинства партнерок виде:
    дата 1.10.2012 уники неуники заказы профит
    дата 2.10.2012 уники неуники заказы профит
    дата 3.10.2012 уники неуники заказы профит
     
  2. unkn0wn

    unkn0wn

    Регистр.:
    22 дек 2006
    Сообщения:
    163
    Симпатии:
    86
    Прокрутил в голове разные сценарии - все ложится ровно, багов не вижу. Только я не совсем понял - под "уником" понимается человек, который перешел по рефссылке?

    Базу по дням - лучше всего добавить в partners поля eod_unique и eod_raw, и создать таблицу aggregate (pid, unique, raw, date), в которой хранить аггрегированном состоянии. В 23:50 сделать селект из partnets (pid, unique, raw, eod_unique, eod_raw), вычислить для каждого pid разницу unique - eod_unique, raw - eod_raw, полученные данные занести разницу в aggregate(pid, unique, raw, date), сделать update partners eod_unique = unique, eod_raw = raw. Кроме того, путем простого селекта (unique-eod_unique, raw-eod_raw) можно отображать статистику даже в течение дня.

    eod - end of day
     
  3. latteo

    latteo Эффективное использование PHP, MySQL

    Moderator
    Регистр.:
    28 фев 2008
    Сообщения:
    1.401
    Симпатии:
    1.182
    А что делать с вариантом, когда $_COOKIE['PartnerID'] уже существует, а пользователь по реф-ссылке другого партнёра перешел? С точки зрения партнёра, нечестно не учесть...

    Помимо кук есть еще множество более новых механизмов идентификации:
    Entity Tags http://tools.ietf.org/html/rfc2616#section-13.3.4 (популярен)
    Хранение данных на клиенте (3 метода) - http://xdan.ru/HTML5-Client-side-Local-Storage.html (не все разрешают)
    Last-Modified для уникально сформированного url`a (извращенно, сложно и ненадёжно)
     
    Extalionez нравится это.
  4. Igor Inkov

    Igor Inkov Создатель

    Регистр.:
    6 май 2012
    Сообщения:
    34
    Симпатии:
    5
    В партнёрках я видел два правила зачисления вознаграждения:

    1. Первому партнёру
    2. Последнему партнёру

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

    Правило номер 2 – при каждом переходе по партнёрской ссылке PartnerID в куках обновляется.
    Таким образом вознаграждение зачисляется тому партнёру, который «довёл» пользователя до покупки –
    то есть, принёс сайту прибыль, из которой он и выплачивает вознаграждение.
     
  5. verfaa

    verfaa

    Регистр.:
    29 янв 2007
    Сообщения:
    371
    Симпатии:
    41
    По поводу какому партнеру зачислять вознаграждение я уже решил - последнему.
    А чтобы предупредить претензии в будущем, я просто напишу в партнёрском соглашении, что комиссия выплачивается последнему партнеру и все.

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

    Давайте обсудим такой вариант:
    Для каждого дня каждому партнеру заводится отдельное поле в таблице БД и в это поле пишется информация об униках, заказах и т.д.
    структура поля такая:
    ID - auto_increment
    id_partner
    unique
    raw
    num_orders
    comissions
    data - Тип datetime т.е. данные вида 2009-06-05 22:55:04


    Как в этом случае будет выглядеть sql-запрос на выборку информации о униках, заказах для партнера с id 7231 за последние 14 дней?
    Может кто-то написать мне этот запрос, т.к. запросов на выборку данных по датам я никогда не писал...
    Тут нужно вычислить текущую дату и затем в цикле перебирать каждый день? Уверен что нет, наверняка в sql есть для этого специализированные функции для выборки данных по интервалу времени.
     
  6. MaximusGladiator

    MaximusGladiator Создатель

    Регистр.:
    15 мар 2013
    Сообщения:
    11
    Симпатии:
    7
    Вы хотите сразу сохранять данные в виде отчета. А отчет должен строиться на основе Данных. Без них у Вас нет данных по каждому визиту (ip адрес хотя бы, сайт реферер), нет данных по связи визита и заказа, нет данных по возвратам. А comissions у Вас - сумма безусловного долга, без временной блокировки суммы к выплате.
    Вам нужна полная структура БД, сохранение всех промежуточных данных и бизнес процессы - продажа, возврат, начисление комиссии, возврат комиссии, выплата комиссии.
    Для статистики в кабинете лучше считать уников просто по ip, тк остальные параметры легко накручиваются.
    В любом техническом вопросе важен изначальный бизнес вопрос, тк чаще всего в виде правильного ответа нужно менять технический вопрос, а не давать ответ на технический вопрос. Ведь Вы совсем не учитываете вопрос качества получаемого трафика и принимаете любую партнерскую продажу, а закончится это сливом низкокачественного трафика и ухудшением ПФ в поисковых системах как минимум.
     
Статус темы:
Закрыта.