traffic and what my ticket result was

Thanks, Kitty--I didn't know that. But probably that wouldn't be an option LL would consider if (as I suspect) doing so would make it impossible for the parcel owner to see the Traffic figures. At this point, they're really not considering removing Traffic data collection altogether, I think because many business owners are still using this as if it were a useful business metric. And, I suppose, in the absence of anything else at all, well... it's probably marginally better than nothing.

What they seem to be saying is that continuing to collect Traffic but disconnecting it from the Search (Places) ranking would require development. (It's beyond me how much friggin' development it could possibly take to force that number always to be zero.)

Yes, but I'm meaning land that is owned by an a avatar, and not group-owned land. You don't own that land - your group does. I'd still put money on that land owners aren't counted.

It doesn't take any development at all to put back what they've already put there once - replace the traffic results with the filtered All search results, which is part of their own "roadmap for search". As I said earlier, I have full confidence that, if they come out with anything new at all, it will be something to appease the people who shout about traffic bots, but keep their numerics largely intact - and quite likely make things worse all round.

The tests that ended yesterday were puzzling.

1. I'd changed the parcel to group-owned and placed an av on it for 102 minutes, after which the av stayed in SL and never logged out. The resulting traffic figure was 92 - 10 short of what I expected.

2. I split a piece of group-owned land from my main parcel (a different sim to the first test) and stood on it myself for 15 minutes. When the traffic was updated, it showed 0.

In both cases, the timing started soon after the traffic had been updated - not far off a full day before the next update, so it was very unlikely that the snapshop time got in the way. Also in both cases, the land had been changed immediately before timing the avs on them, and I'm thinking there may be a delay following a change in the land.

Yesterday, I stood my main alt on the second parcel for 15 minutes and the resulting traffic is 17. The extra 2 could be due to one or two other people or, more likely, because I haven't been timing with a second hand and the start and finish times are not as accurate as they were a year ago when I first tested. The alt had been used on the first parcel when the parcel was owned by my name (not a group) and she didn't count at all for traffic.

All in all, and together with Sling's findings, I think it's safe to conclude that traffic is simply avater minutes on the parcel, as it was the last time I tested.

On a sidenote: Traffic IS an important metric of course for any business owner, even when it would not be used anymore in Places Search. It gives my a general idea of how well I am doing regarding visitors and the time they stay.

At my new store I check traffic daily to see the trend: do the marketing things I did, actually bring more people into the store, and do they stay for a while?

Of course my visitor counter gives my statistics every 24 hours, but that does not give me a clue on how long they stayed. Traffic does.

Then it's probably a freebie visitor counter. So *much* more information is available by script than from the (current) Traffic metric that anyone still relying on it for business decisions is really losing out. At a bare minimum you can know how long visitors stayed, where they spent their time, whether they returned, and such demographics as payment-info status and rez date. By integrating this info with custom vendor scripts one can correlate all this with detailed purchasing information.

And going forward, if we can just get past "Plain Old Traffic," the Lindens have even more valuable information that isn't available to scripts. For example, they can know if a visitor came from a Classified, from a listing in All Search, from a saved Landmark, by TP from another avatar, from the Map--critical information for evaluating a marketing strategy.

But I think it's fair to bet that yet again, the pro-Traffic folks--intentionally or not--will lobby successfully to keep Traffic useless for anything but gaming.

Traffic is clocked up for parts of a minute.

I set up three adjacent 16m parcels in a row. Call them A, B and C.
A and B are in one sim. C is in the adjacent sim.
I scripted a prim to spend 45 seconds in each, moving ABCBABCB.........
I sat a MetaBolted avatar on it and left it for a few hours.

Traffic built up on the parcels although the avatar was never in any parcel for more than 45 seconds continuously.
The actual numbers from the first run were not useful in determining any effect of a 45 second visit as opposed to a visit of a minute+. The setup and testing would have caused a number of longer visits. A rolling restart also hit things on the head.
No matter - the idea was to check if sub-minute visits registered in the first place and to follow that up with measurements of the effect and to check for any possible advantageous effect of arriving in from another sim.

My initial quick and nasty checks indicate that traffic is recorded in units of less than a minute. So - no clocking up full minutes of Traffic for a 10-second visit



From my last test, I know that I have to run it for two days to get to a steady state. This is due to the recording time windows and the delay between recording and setting the count on the parcel.
This new test needs some extra time due to the recording windows being different in the two sims.


I've just cut a fresh strip of 16s in order to get a zero start point, and let it rip.





Well, it's sumptin' to do innit?

If one visitor arrives and goes AFK for a few hours, that messes up the average visit time.
Neither Traffic or the visitor counter can tell you how many arrived and TP'd out immediately.

Traffic (when not gamed) is just a vague indication of 'buzziness' of a place.

Right, but (as I should have mentioned above) a Real Script™ could filter outliers and/or give a measure of the dispersion around that "average stay" number.

Raw Traffic is just so... raw.

Interesting test, Sling. With the new strip of 16s, you may initially find some odd results because the land has changed. Two of my tests produced odd results when I started counting the minutes right after changing the land - in one case it was simply cut from a bigger piece which zeroed its traffic count. With that one, there was no change of owner (group-owned), and yet my 15 minutes on it, from the moment of change, counted for zero.

I forget why, but I suggested earlier that the parcel's count may be increased by 1 when an av lands on it, which may be the reason why part minutes are counted. OR >>>

If I had written the traffic counting, I would have decided that absolutely exact numbers aren't necessary and I would have written it so that the sim, which stores the ongoing counts for its own parcels (in my method), adjusts the counts on a 1 minute timer, rather then each avatar in the sim having a timer. In that case, walking on and off a parcel would only count as 1 if the timer fired during the few seconds that it took to walk on and off. There's a 3 to 1 chance of the timer firing during a 45 second stay on a parcel, and I would hazzard a guess that part minutes count only when they coincide with the sim's traffic timer firing but not otherwise. It would amount to the same thing if the 1 minute timer is grid-wide.

ETA:
The old dwell method required much more overhead than that simple method. A record had to be kept of places visited and time spend there for all avatars that logged in during each 24 hour period. As the population increased, that might well have been the reason for changing the counting method - not the reason to stop paying dwell, but the reason to change the counting method.

The numbers from my initial rough test point to the parcels in a sim being checked for avatar count on a 1-minute timer. Such a thing would be by far the easiest way to code it and would impose the least load.
The sample wasn't pure or large enough, but the numbers did not seem to account for all of the alt's time.
In that case there would not seem to be any scoring advantage in 'flitting' bots between traffic-gamed parcels.

If traffic injectors are flitting bots then this may be in an attempt to stay under the radar rather than to exploit some traffic-scoring hole.

In setting up the test I was looking for a killer reason that LL had become concerned about traffic_for_hire operations in particular.

To be honest, it's hippo's visitor counter
Of course I could script my own, and put in the extra data as well, maybe an idea for the future, but are there counters available that do this already?


Invaluable information!! Really that would help me a lot, because it is hard to figure out a marketing strategy without this stuff.


Well the question is, are there pro-traffic folks? We know that removing traffic as search parameter would kill the current bot system, and I think not too many people are against that.

In my opinion, there is only one party that is pro traffic, and that is LL themselves. Removing traffic entirely as a search metric would kill enough bots to make their figures drop dramatically. And that is what they probably do not want. Imagine tomorrow instead of 75k only 60K is online...

If the timer is run independantly by each sim, then it could be that someone found that a sim-hopping experiment produced additional counts for a single av, by coincidentally hitting the timer in each - the timers wouldn't be synchronised. It wouldn't work on different parcels in the same sim because they are on the same timer. Maybe it's something like that that gave rise to the wiki entry.

That's if that the counts are done independantly by each sim.

I'd say that it's done independently by each sim. The traffic updates in the two sample sims certainly can be hours apart from my tests.
If I did know the precise second at which the avatar count was taken in each of the sims I'm testing in, I could double the effect of my alt by having here there art the right times. However, I'd guess that this changes each time a sim gets rebooted. It would be very 'iffy'.

I was looking for that sort of effect - a good reason to flit bots - in my tests.

You're not coming over to the dark side are you, Sling? j/k

Are you sure about that? It would surprise me if they are. I haven't checked to see roughly when the public traffic nunbers change for different sims because the way see it working is that the central system polls each sim for it's counts each day, and all at the same time (not taking into account the amount of time it takes to poll round all the sims). I see the public traffic numbers stored centrally - at least. Perhaps each sim keeps the current public numbers for the About Land box, but I can't see the Places tab search polling sims in order to produce a set of results. I see those being acquired centrally, which leads me to think that all the sims are polled in one operation each day.

The time traffic changes has itself changed, it used to be around 8pm UK time, it's not now.

Absolutely sure about the updating of the traffic counts being asynch.
!'m looking at the row of 16's right now.
In one sim, the count has been updated (sometime in the past 2 hours).
The other sim is still not updated. I'll check back in an hour.

It's not mission-critical that all sims get updated at the same time. Traffic is only a rough guide to 'popularity'. Sims can do their own timing of updates. They either push their data at the central server or are polled. If polled, then they can just serve up whatever data they have at the time. It makes no real difference. Given that we've seen "Traffic did not get updated" status a few times, it may be a polling mechanism, but it can still be a poll of "whatever counts you've got right now".

Just updated for me on the parcel that used to update at 8pm, maybe it's just an ordering thing and I've ended up on some different server due to updates over time.

It used to update for me at around 8 p.m. my time too, Ciaran, and before that it updated around 4 p.m. It changed when they had a few days without any updates. Now it updates for me sometime when I'm in bed and I don't turn in until 2 a.m. But it never occured to me that all parcels weren't updated at around the same time, and I can't now say which sims I was looking at. Now it seems that they're not. Sling's tests show it, and Ciaran's updating already today whereas mine doesn't update until the wee smalls, show it. It's of no consequence to us but it's interesting just the same.

I agree that it's not "mission-critical" to SL, Sling. It just never occured to me. I've never heard that the Places numbers differ from parcel numbers, and I'm sure that the numbers are stored centrally at least, so either method would do - polling the sims, in batches maybe, or each sim pushing its numbers, probably after it determines that 24 hours have elapsed since its current counts began, which as you suggested, Sling, is no doubt started when a sim comes up. One way of finding out is jotting down the time of a sim restart and checking when the traffic in it updates, although that may not work - it depends on how much of its data is kept from before a restart.

I'm not sure about when during a 2-hour window, the first sim's count updated.
All I can cast-iron guarantee is that the second sim was updated at minimum 25 minutes after the first.

The moment I allow myself to get curious about something I have this awful compulsion to find out as much as possible - just for the sake of it!
It's intensely irritating that I might have to code up my own bot client in order to discover some sily detail like the timings of updates.
Once I start reading the viewer code in earnest, my RL time is going to be totally screwed.


Anyhoo - far more curious that the timing of the update, is the fact that the update is lagging far behind events on the ground.

I started my alt moving over the fresh row of 16's about 12 hours ago.
Although the old row of 16's in both sims have gone through a traffic count update at this time, the traffic for the new row is still at 0 for both sims.


The answers to all of this are not of earth-shattering importance.
It's just a minor curiosity.

At the same time..... WTF??

Aside: Through all of this discovery process I wilfully ignore the Voices In The Head that are saying "With all the other borkiness evident in SL, you actually think that the Traffic bit will behave consistently??"


As for Phil's j/k query about me going over to the dark side ......
I'm just getting a feel for how things work and can be gamed before Jack Linden does his blog on traffic/search gaming.
If the lethargic slug that is LL response_to_stuff_that_actually_matters gets to the stage of publicly getting ready to do something about it, there must be some serious shit going on.

The 0s may well be what I suggested, Sling - you'd changed the land by cutting it. When I did that, but didn't change the owner (group-owned), my 15 minutes on it immediately afterwards hadn't counted at all when it updated very roughly 20 hours later. With the other parcel, where I changed the owner but didn't cut it, 10 minutes went missing. There seems to be a delay for some reason after making changes to land. At one point, I was even wondering if the figures don't become public for 24 hours - a day in arrears - but that's not the case.

As a followup:

I ran the alt over the three new 16m parcels for 14 hours - until an invalid region handoff dumped her.

After the traffic updates in both sims - which were at least 2 hours apart - the counts in the parcels were as follows
Parcels A, B, C
277, 557, 269

A and B are in one sim, C is in the adjacent sim.
B has about double the traffic of the others. This is not surprising as the alt moves ABCBABCB... , spending 45 seconds in each parcel, visiting B twice in each full cycle.

The total count over all three is 1108 - over 18 hours of traffic for only 14 hours of bot time.
The total count for A an B is 834 - 13.9 hours = the total time the alt had spent over all three parcels !!
Parcel C got a 'bonus' 4.6 hours of traffic.

It appears that traffic is sampled every minute and accumulated by reference to the number of avatars on the parcel at the sampling instant.
There does not appear to be any bonus advantage in a bot simply arriving into a sim.

The 45-second visits meant the the alt arrived into parcel C sim every 3 minutes. The 45 seconds that she spent in that sim happened to encompass the sampling instant of that sim, and did not encompass the sampling instant of the AB sim. It could have gone other ways!

As a way of boosting traffic it seems a bit iffy. It depends on the sampling instants being different in the sims in which parcels are being gamed. This is very likely, but the bots would have to be in a parcel at the right time. Something like visibility of sim up-time might enable prediction of the traffic sampling instant.

Even if the timing can be got right, this is no score advantage to someone who only wants to use their own bots to game a parcel in a single sim.
To someone running a traffic-for-hire / traffic_injection operation there would be advantages - getting more bang per bot over a number of sims.

Flitting bots would in any case help to keep them under the radar. I think Elan ran a check a while back, looking for avatars that stayed in a parcel but did not move (much).



It remains to be seen why jack Linden considers traffic_for_hire operations to be "clearly not cool".
Perhaps LL have seen a server load imposed by flitting?
Maybe they think in some broken way that gaming traffic with hired bots is in some way more distasteful than gaming traffic with roll_your_own.
Maybe they consider that hire operations are hastening the day when the sheer volume becomes unacceptably damaging to credibility.

That is very interesting stuff, Sling. Thank you for doing the tests. Personally, I don't even want to run the stationary bots, so I have no interest at all in flitting them across sim borders. I just find it very interesting.

I don't know Jack's reasons for what he said but I am totally convinced that LL doesn't do anything for the benefit of users - not even their efforts of cleaning up the mainland. Sim hopping bots certainly hit sim resources, and I recently suggested (I think in this thread) that the concurrency increases in recent months is likely to be largely bots, because of the increase in the concurrency levels when I get up each day. I.e. going from an overall peak of 60k+ to 80k+ is largely taken up by the trough increase, and I don't think that the trough increase is wholly due to real people logins. I think that the majority of it is due to bots, and those bots may be largely of the "bots for hire" type. If much of that type is moving all over the place, using a lot of resources, then even LL might be interested in doing something about it - for their own benefit rather than for the benefit of users.

ETA:
Incidentally, the non-exact numbers are no doubt due to the 45 second intervals missing a few timers along the way.

This is fascinating data, and I think pretty determinative of what's actually going on. But I don't agree with the analysis here:

I think these data indicate, rather, that an agent being in a parcel for any part of a minute is all it takes to be counted as Traffic.

In 14 hours, there are 1120 intervals 45 seconds long, which is pretty darn close to the 1103 that were observed. So pretty much every darn one of them counted. Moreover, given the 45 second dwell interval, if every visit counted, Traffic scores are as follows:

Predicted: A=280, B=560, C=280
Observed: A=277, B=557, C=269

And it's fairly unlikely that a fixed once-per-minute sampling instant could be aligned in all three parcels to catch each visit. In each of A and C, the probability is 75% that such a sampling instant would fall in the 45 seconds of the agent's visit, repeating every three minutes. But B is much less likely, because the portion of a minute that is represented by the agent's visit shifts by 30 seconds (90 mod 60) from one visit to the next, leaving only a 30 second overlap in the minute-clock when the sampling would have to occur--a 50% probability. So, the likelihood of all this lining up is 0.75 * 0.75 * 0.5, or about 28%. Possible, but unlikely.

[EDIT: Changed the numbers above because I'd previously thought the B visit interval processes by 45 seconds and overlapped in the minute clock by 15 seconds. That was all wrong--it processes by 2*45 seconds, so the overlap is 30 seconds, a 50% probability.]