Question About Balancing Speed vs Protecting Your Lander (10)
I hear a lot about the need for fast page loads and redirects on mobile. Given that, what's the best way to redirect someone from your lander to the offer? Doing a 302 redirect through your tracker would be the fastest, but this exposes your lander to the affiliate network and advertiser. On the other hand, hiding your lander requires something along the lines of a double meta refresh which would add a considerable amount of time to the redirect. Let's assume your lander is 100% compliant and you're working a unique angle. Do you opt for the 302 and expose your lander/angle, or do you hide your lander and take the hit on the lost conversions due to the slow redirect?
Myself I don't care too much for trying to hide things from affiliate networks since LP ripping is going to happen in the reverse direction anyway.
I would recommend split testing it.
Send 50% through a DMR, 50% through a 302. Can try SSL + 302 as well. See how much of an impact it has.
IMO better to be first to market and push hard than sacrifice profit to delay the inevitable. Better yet, get to a position where competitors can't go head-to-head with you because you have built a series of advantages that they cannot steal.
Awesome question. Just wanted to throw that out there.
I'm in the same camp as Zeno on this one. Speed = ROI. I'm prepared to risk exposing my lander to (trusted) affiliate networks for that.
OTOH, I know that some of our other STMers are big fans of the ol' double meta refresh - I'll be interested to hear the other point of view on this one!
It is possble to kill all mobile referrers without redirects
Originally Posted by constantin
This is the best I came up with. (and it took me one week). I use the rel=noreferrer tag on my CTA link on my LP. This blanks out 70% of people's referrer on mobile. Then I use a PHP script I had made that checks the referrer and redirects the person to HTTPS if the referrer is still there or to the offer if the referrer is in fact gone.
Only 30% of the people will end up going into HTTPS so you reduce the speed loss. If you want to really be safe, you can add another PHP referrer checker after the HTTPS and boot people that still somehow have a referrer. If you combine this with maybe changing your LP URL weekly, I feel like its pretty safe.
Tell me what you guys think of this setup or if it can be improved in any way. I also REALLY want to hear constantin's no redirect approach.
Ideally, I'd like to be creating static landers so I can throw them up on a CDN. I don't know what technique constantin has in mind, but I'm guessing it requires using PHP. As Zeno mentioned, SSL + 302 might be the best way to go. Here are a few other ideas:
1) If you know what the referring domain(s) of the traffic source is (and you know it's going to remain constant), you can cloak your lander based on referer.
2) You can utilize a pre-lander and cloak based on PHP Session. I.e., send your traffic to the pre-lander, create a session and a unique token, then redirect to the real lander. On the real lander check for the existence of the session and the token. If it's not there, cloak.
3) And of course, you could cloak based on device, screen resolution, etc.
Other ideas?
Hey lwpack, I have tested these methods myself and let me share my results :
1) A lot of mobile browsers won't pass the referrers so it will fail. From my tests the increase in traffic loss was about 30%.
2) Tried this too, it worked a bit better but the extra traffic lost was about 20%. I can't be sure why but I guess some browsers have cookies disabled and that causes it.
3) That wouldn't also be very accurate since you would rely on an external library to do the detection and it will never be 100% correct. I didn't test but I am pretty confident the loss would be pretty big.
The most basic check that loses little traffic is detecting if it's a mobile device. It won't help a LOT but can weed out quite some people if you also ip-ban them if they don't browse from a mobile device and cookie them too.
Wow, thanks bbrock! Looks like I have a lot of learning to do in the mobile space. Regarding #2, if the loss of traffic is in fact due to browsers disabling cookies, you should be able to get around this by passing the session id as a query parameter, no cookies required.
Home > Paid Traffic Sources > Mobile