Topic: notcounted traffic is going to trades and influencing return

[bbhrucy79]

ok, notcounted traffic (after 15 clicks) is being counted under the 'notcounted' system trades column, it's fine.

It is going out to trades and galleries which is also fine.

However I notice that it is influencing the dynamic scheme (built on return). The part of the notcounted traffic that goes to trades is being added up to the 'out to trades' section and therefore fucks up again my dynamic scheme that is built on return.

This is BS!!

Why the hell is it 'notcounted' if TP is actually counting it and adds it to 'return' to trades!!

and what about nocookie?

It is also going out to trades (which is fine), however it is also added up to 'out to trades' and counted!

[ip0li]

forwarded to kildoozer.

[Kildoozer]

Fixed on my side.
About nocookies. I can add them to 'COUNTED CLICKS' section also (out settings), to add possibility don't count'em also. Is this ok for you?

[bbhrucy79]

hello,

Thanks 4 fast reply!

I think if we could have the decision to count or not count the nocookie (to the out to trades) would be great - as you mentioned. Nocookie is a mix of robots and normal surfers, right?

Yes, that would be great, Thanks!

 

[bbhrucy79]

Killdozer, hi

I have Version 1.0.7 build 38.

I have count clicks from user: 15 clicks

After 15 clicks, clicks are collected (for administrative purposes) under 'notcounted' column.

In fact however, those clicks are going out to the galleries/trades, which is fine.

The problem is: the clicks going out to trades (I am talking about the 'notcounted' hits) are administratively added up to the 'out to trades' counter.

So, they dilute dynamic skim.

Imho, notcounted hits should go normally to trades/galleries as they do (because I set in table of specialized out settings to be treated as normal traffic), HOWEVER these should not be counted administratively = they should not be added up to trades out !

This is still the case.

I am unable to use dynamic skim based on return, because I cannot get realistic figures.

Imho, the traffic that should be administratively 'counted' and added up to the 'out to trades' should be real human traffic as well as only traffic that is within the 'clicks to count from user'.

So:

1. clicks to trades, coming from trades (this is already like this)
2. bookmark traffic (this is already like this)
3. search engine traffic (this is already like this)
4. no trade human traffic (this is already like this)
5. no ref in traffic (this is already like this)

robots traffic definitely should not be added up to outs to trade administratively, and you already fixed that.

nocookie traffic the same, and you fixed that as well (we have choice to count it or no)

HOWEVER: notcounted traffic!

This should also go normally out as regular traffic, right, since it is HUMAN traffic as well!

BUT!!!!

It should not be added up administratively to the 'out to trades', because it is more than the 'clicks to count from user value.


Please tell me if you think differently.

 Let me tell you: after upgrading to Ion Cube version I used dynamic for one day (based on return of course). I was not around, I did not even look at my TPs for one day. Result after one day: I lost 70% of my traffic.

Why?

because 'notcounted' was huge, (people clicked much much more time than 15), and all that was going out to trades (which is fine), however It was counted and added to 'out to trades' value, so my return looked great, and TP switched to very friendly skim (based on my dynamic rules).

And I lost massive traffic.

For now, I still cannot use dynamic based on return.

Regards!

 

[Chris]

I think i will second that...
I m not feeling comfortable to use dynamic skim without constantly keeping an eye on my stats...

[ip0li]

Hi,

our opinion and what all tests on BIG sites(100k+/day traffic) shown is that it's not WISE to use method you described. Why? Because you will loose a lot of return to trades.

Not counted traffic is normal surfers who clicked more then X times, X=defined value (count first x clicks per each user).

Idea behind count first X clicks is not at all in filtering traffic etc. It is INVENTE for 1 purpose and that is SHOW REALISTIC prod from trades and that is it.

So let me sum it up, notcounted SHOULD go to trades because only reason why we added that feature is to show REALISTIC prod, so not to show insane productivity because couple users clicked 100+ times.

Also I do not understand how can this affect your site based on OUT ratio, let me repeat, notcounted=normal surfers, so basically you send to trades NORMAL SURFERS and you dont count their clicks just to get more realistic AVERAGE prod.

Cheers

[allniche]

I suspect that what could have happened is that somehow a bot escaped detection via the other detection means (they can be sneaky) and then proceeded to run up lots of clicks with the regular percentage going to trades.  But since it's a bot not interested in other sites it didn't click on the trade's sites after being skimed. That gave a of crappy prod to his trades.  Then to top it off the favorable dynamic skim kicked in based on those Not Counted clicks out and killed his sites even more. I could be wrong but this seems possible.

When I ran skim sites I personally always chose to bite the bullet and just send "Not Counted" traffic always to galleries instead of trades.  My reasoning was that I believed there was a much higher probability of NotCounted traffic being bots and if I sent them to trades then I would likely be sending more bots to my trades.  That is one of the things I really like about Trade Pulse - it is extremely configurable - more so than any other trade script I am aware of.  Please, definitely don't lose that.  What is best for one site or webmaster may not be best for another who has things site up a different way and works on an entirely different theory.

[ip0li]

Yes and as U already said, you can simply use send notcounted to galleries 100% using settings/out/TABLE OF SPECIALIZED OUT SETTINGS.

So I don't see reason why we should do it by default .

[allniche]

Yes and as U already said, you can simply use send notcounted to galleries 100% using settings/out/TABLE OF SPECIALIZED OUT SETTINGS.

So I don't see reason why we should do it by default .

I don't think it would be good to do it by default either.   Some might want it to count. I think in his case though if he didn't have it so it counted (for the dynamic skim) the favorable dynamic skim would never have kicked in.  So all the bad Not Counted hits would still give him crappy remote trade prod but the damage would be a little less because the new favorable  dynamic skim wouldn't have triggered.

Your approach of having a check/radio box to determine whether a given type of traffic counts towards the dynamic skim is a good one I think.  You guys have already been working on overdrive the last few weeks though witht he fixes and features.

[bbhrucy79]

I suspect that what could have happened is that somehow a bot escaped detection via the other detection means (they can be sneaky) and then proceeded to run up lots of clicks with the regular percentage going to trades.  But since it's a bot not interested in other sites it didn't click on the trade's sites after being skimed. That gave a of crappy prod to his trades.  Then to top it off the favorable dynamic skim kicked in based on those Not Counted clicks out and killed his sites even more. I could be wrong but this seems possible.

hi allniche!

Yes, I think this is exactly what happened! And of course I could send notcounted traffic to galleries always, but notcounted is also human traffic who just happens to like my site a lot. Thanks for brainstorming the situation because I think what you described actually happened.

Looks like there is no good solution. I could increase the clicks to count value. By the way, why is it 15 by default? Basically, if you have lots of trades, you can increase this value, so even in case of lots of clicks from one unique (say, 30 clicks) will be ok because they will be distributed just fine to your trades without sending the same unique to a certain trade multiple times?

[ip0li]

It's 15 by default since when we started experienced traders with a lot of traffic recommended us that value.