Caps are the daily routine of an arbitrageur. If you pour regularly and with a good volume, it is a headache to make sure that you don't give more leads than you should.
В Keitaro there is a built-in function for capping - limitation on the number of accepted leads on-offer:
But it is not convenient to use this thing at all. To begin with, let's see what the creators of this function write about it tracker:
"The functionality is useful when an advertiser accepts a limited number of leads (conversions) and then stops processing your traffic. In this case, you can set an automatic change of an offerer to a similar one from another advertiser or affiliate program. When activating the function, you can choose the daily limit, time zone of conversion accounting and an alternative offerer to which the traffic will be switched."
But it is impossible to pour such a scheme on the gasket-land bond! I.e. imagine: you are pouring such Titan Gel. You have set a cap of 100 leads on the offerer. The user gets to the pad, which already indicates the name of the offer - Titan Gel. Then he clicks on the link, tracker determines that the drop is overfilled and sends you to Erogan, let's say. This is bullshit! It's a completely useless feature. Unless you make some kind of "universal" pads without mentioning the offerer on them. And I'm not even talking about the variant when we have several pads for one product.....
All of this we are about to solve and fix! Download the ywbcapfilter.php file from here.. Open it in any text editor and replace on lines 34-35 your API key and the ip address (or domain) on which your tracker. Yes, if your time zone tracker not Moscow - set it down there below the code.....
Then we put it in the application\filters folder inside. Keitaro. Logging in tracker. All right, now we're gonna create tracker campaign and in it a stream for Titan-Gel. The stream can contain any number of Titan-Gel proclams and lends. Next, go to the Filters tab. Select ywbcapfilter and set the drop value:
Then we create a second thread on Erogan to get users there when the drop is overflowed.
How does it all work? It's very simple. For every single person that comes in tracker click our filter looks at what we have in the flow of offers, for each of them looks at how many sales there are today, summarizes the sales and checks their number with the set cap.
DISCLAIMER: under the hood filter uses a couple of api calls trackerthat can slow down the speed of displaying your pads! On tests the speed degradation was about 0.2 seconds, but check it on your hardware and your traffic volume!
And I remind you that the project exists only because of your donations.) Pour in the plus, gentlemen, and don't overfill the mouthpieces!
Hi. And users who already got on the first offer where will they go after the capa closes, on the second or on the first?
the whole point of the filter is that if the drop is closed, the user gets to the next offer. That is, to the next thread in Keitaro.
Уведомление: Maximizing profits using the "multi-armed bandits" algorithm in Keitaro - Yellow Web
Salute! As a follow-up to this topic:
This option is great for working solo, but for a team working in a single trackernot so much anymore.
Let's imagine the situation in a vacuum, 3 web run on the offerer each of their companies, some of whom went to who is not very. All together they can pour let's say 100 leads.
Theoretically, I can imagine how to modify your script. In addition to the quantity, I would add an input with the name of the Offender, which in the report request would search for this Offender name in the names of the bundles (if the track has an order in the names).
On the other hand before I even start I realize that the processing time will fly into space and in place of 0.2 of yours, will be times or dozens of times longer.
If it were possible to cache the list of icons of the required landing pages at the first launch, and further pull the report by it, perhaps it would fix the situation.
Before getting into this thicket, I'd like to hear your expert opinion on whether it's worth going to such trouble)))
Hey, Anton.
I don't quite understand why this option is not suitable for the team? Here you have an offer with a cap of 100 leads. 3 webs are pouring, some of them got in, some of them not so much. Together they can pour 100 leads, right, after which the filter will not let in this stream. What's the problem? That's how it's supposed to work.)
Maybe I just don't really understand the principle. If I understand your scheme correctly, capex is only counted within one company, right?
What if each of the guys has a different company? Someone has one promo with one approach, someone else has another, but all in the end for the same offer that should be tracked by the capa
The cap is counted by those bandings/offers, which are set in the black stream within the campaign. If the bavers have the same set of lendings, then the calculation will be correct. If one of them pours on some feeds and the other on others, then yes, it won't work.
Hi ! And if I have 3 offers ( each of them goes to 3 partners: "pp1, pp2, pp3" ) that is a total of 9 offers. There are 4 webs in the team, which should pour traffic on pp1 - 20 leads per day on pp2 - 10 and on pp3 - 10. Each web has its own companies, how can we combine their companies - that is, count the leads from all companies and if the limit is reached, say on pp1 in 20 leads traffic went to another pp and vice versa?
You don't need to combine campaigns, because the filter counts the cap not by campaigns, but by providers.