Ищу Скрипты партнерских программ

[aladin2008]

А что есть руссифицированная версия?

 

[cartman14]

подскажите существует ли в продаже или в свободном доступе скрипт партнерки под фарму?

 

[aladin2008]

партнерка под фарму

подскажите существует ли в продаже или в свободном доступе скрипт партнерки под фарму?

Тоже интересует подобная партнерка, различие лишь в том что будет только один вид товара. Хотя возможно и не только под фарму???

 

[anmar1972]

Та-же история , очень нужен партнёрский скрипт для фармы или что-то похожее.

 

[G-Null]

Будьте добры, подскажите работал ли кто с post affiliate pro 3.16 на больших объёмах трафа, 100-300к/сутки и десятком-другим аффилиат-аккаунтов(в частности как стата себя ведёт)? Так то скрипт вполне хорош(всё что нужно можно в сорцах подправить), но интересует именно нагрузка(то есть не жрёт ли он лишнего).
Может быть есть у кого какие нибудь наблюдения/советы по оптимизации. Также интересует вопрос уязвимостей под эту версию, если кто знает отпишите плиз, что следует исправить.

 

[benladen]

Большие нагрузки

Вот наконец то и затронулась тема больших нагрузок.
Недавний опыт показал как 4-я версия глючит и какую нагрузку создает. Глюки выразились в том, что она не считает посещения и продажи. В итоге было принято решение - перевести все на старушку 3.16. Благо что она нормально лечится и не глючит.
Для скрипта был выделен целый сервер:
Проц на сервере i7 920
памяти 8 гиг
винт 750 гиг
канал 100Мб
Операционка FreeBSD 7.2
Были установлены:
Apache 2.2
Mysql 5.1
PHP 5.2.12
и фронтендом к индейцу был поставлен Nginx 0.83
Суточный траф на партнерку шел от 320000 до 500000 уников траф неравномерный, пиковые нагрузки замерить не было возможности.
Под нагрузкой свободной памяти на сервере оставалось 200Мб.
Апач в одиночку лег бы намертво, потому как именно он сожрал память, но nginx стабильно держал нагрузку и перебоев в работе сервера не наблюдалось.
По техническим причинам и по вине хостера пришлось ставить именно связку Apache и nginx
При возможности от апача отказались бы совсем и голова бы не болела о наличии свободной памяти.
Тем кто будет устанавливать РАР4 или даже 3.16:
Если поставите на сервер memceched и eaccelerator - получите нарабочий сайт партнерки. Точнее он будет работать частично - откажет авторизация, диаграммы и личные кабинеты.
Эти два компонента пришлось отключить, а с ними башку сломали в поиках бага.
На втором сервере установлена связка: PHP-FPM, nginx, mysql.
Памяти 1 гиг (!)
винт 80 гиг
Celeron 2400
установлен РАР3.16
PHP-FPM потребовал дополнительных настроек для корректной работы почтовой системы РАР.
memceched и eaccelerator не устанавливались.
Под той же нагрузкой (320-500к в сутки) сервер сожрал всего 600мб, свободной осталось 200Мб. Active conections на stub'е показывал 3500 и работает как часики, перебоев нет.
При таких нагрузках учет кликов и продаж(посещений) идет без ошибок.
Если сервак перестанет справляться с нагрузкой, то масштабирование сервера будет сделать гораздо проще благодаря использованию nginx. Просто будет добавлен еще один-два сервера бэкендами к основному и проблема решится. Тем более что nginx позволяет сделать все на ходу, без перезагрузки сервера.

 

[9balov]

может есть у кого партнерка
Auction Affiliate System для PHPProbid ?

 

[aressto]

benladen
спасибо за столь информативное сообщение. Какую именно версию четверки использовал? там почти каждую неделю новая.
Обращался ли в суппорт?


Меня четверка привлекает тем что там есть репликатор сайта и распространение его в XML (для инет магаза, показ позиций магаза на сторонних сайтах).
Больше я нигде подобного функционала не видел. А разрабатывать такой функционал под конкретный конкретный скрипт инет магаза + правильно все счетчики, панели для партнера и прочее это влетит в копеечку.

 

[G-Null]

benladen, также огромное спасибо за отличный ответ!
Если не затруднит ответь плиз и на это )
1. В одном из своих постов ты говорил, что у PAP в некоторых случаях могут быть сложности с отслеживанием покупки(Я бы сказал иногда практически невозможно отследить продажу по биллинговым скриптам выполняемым на других сайтах, а не на сайте где установлена сама партнерка). Не мог бы немного пояснить, что конкретно это за случаи?

2. (320-500к в сутки) - это именно клики ? (то есть идёт запись каждого отдельного клика в таблицу wd_pa_transactions) или это показы? (то есть идёт суммирование показов с одинаковыми значениями страна/час/баннер, и пишется это в impressions)

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

4. И если не жалко ) Если знаешь какие нибудь баги(или уязвимости) в версии выложенной тобой(http://nulled.cc/showpost.php?p=839919&postcount=77), не мог бы указать на них(просто выкладывал её ты уже давно, возможно за это время приходилось исправлять что нибудь). Пока вроде всё хорошо, кое какие вещи уже аккуратно добавил сам(саб-акки, определение страны), но вдруг что нибудь всплывёт..

5. И последнее, возможно просто знаешь как такое сделать. Можно ли каким то образом в отслеживаемых магазинах скрыть пути до сайта с партнёркой. То есть чтобы в магазинах в открытую не писать <script id="pap_x2s6df8d" src="партнёрка/scripts/sale.js"(в случаях когда не хочется палить партнёрку). Понятно что можно засунуть это куда поглубже и зашифровать, но всё же может есть возможность прямого взаимодействия с пхп самого магазина, чтоб он сам ставил партнёрские куки и передавал эту инфу уже серваку с партнёркой. В пап4 как я понял такое есть, реализует это класс PapApi вроде, а в тройке нету ли каких либо путей организовать всё подобным образом ?

6. И просто из интереса, какой понт делать первичные ключи буквенно-числовымми (char(8)), да и ещё потом перед занесением каждой новой записи генерировать его в пхп и делать запрос к бд на предмет проверки его существования. Не проще ли было сделать просто bigint с autoincrement(те же 8 байт и в 5кк больше возможных значений без дополнительных запросов).
Просто напрягает такая ненаглядность айдишников при непонимании смысла таких ключей )

---- все вопросы по версии 3,16

 

[benladen]

Если не затруднит ответь плиз и на это )
1. В одном из своих постов ты говорил, что у PAP в некоторых случаях могут быть сложности с отслеживанием покупки(Я бы сказал иногда практически невозможно отследить продажу по биллинговым скриптам выполняемым на других сайтах, а не на сайте где установлена сама партнерка). Не мог бы немного пояснить, что конкретно это за случаи?

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

aressto:
Меня четверка привлекает тем что там есть репликатор сайта и распространение его в XML (для инет магаза, показ позиций магаза на сторонних сайтах).
Больше я нигде подобного функционала не видел. А разрабатывать такой функционал под конкретный конкретный скрипт инет магаза + правильно все счетчики, панели для партнера и прочее это влетит в копеечку.

Кстати в ней тоже есть репликация сайтов и если с напильником посидеть над ней то можно прикрутить что угодно.

2. (320-500к в сутки) - это именно клики ? (то есть идёт запись каждого отдельного клика в таблицу wd_pa_transactions) или это показы? (то есть идёт суммирование показов с одинаковыми значениями страна/час/баннер, и пишется это в impressions)

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

И если не жалко ) Если знаешь какие нибудь баги(или уязвимости) в версии выложенной тобой(http://nulled.cc/showpost.php?p=839919&postcount=77), не мог бы указать на них(просто выкладывал её ты уже давно, возможно за это время приходилось исправлять что нибудь). Пока вроде всё хорошо, кое какие вещи уже аккуратно добавил сам(саб-акки, определение страны), но вдруг что нибудь всплывёт..

Насчет багов и дырок не заморачивались. Многие фокусы по защите делали средствами сервера. Весьма помогает в работе.

И последнее, возможно просто знаешь как такое сделать. Можно ли каким то образом в отслеживаемых магазинах скрыть пути до сайта с партнёркой. То есть чтобы в магазинах в открытую не писать <script id="pap_x2s6df8d" src="партнёрка/scripts/sale.js"(в случаях когда не хочется палить партнёрку).

Не знаю как. Не было нужды. В 4ке есть механизм прямых ссылок, но 4ка глючная. По крайней мере в нашей 4.2.3.2
Более свежих нету, кончилось халявное время обновления.

И просто из интереса, какой понт делать первичные ключи буквенно-числовымми (char(8)), да и ещё потом перед занесением каждой новой записи генерировать его в пхп и делать запрос к бд на предмет проверки его существования. Не проще ли было сделать просто bigint с autoincrement(те же 8 байт и в 5кк больше возможных значений без дополнительных запросов).
Просто напрягает такая ненаглядность айдишников при непонимании смысла таких ключей )

А вот тут мы тоже думали как бы сделать autoincrement. Из-за нехватки времени плюнули на эту затею.
Есть еще задумка поковырять ее на предмет создания аккаунтов для продавцов, что бы каждый видел только свою кампанию и свои банеры-ссылки.
Опять же, проще написать заново