How to kill your business without really trying

Why only have one appear in search?

If both appear in search (with different name/descriptions), you'll have the UUID of both the easy way once they get listed in search.

After you join you'd compare to see which UUID the new parcel ended up with (small parcel's, large parcel's or a new one entirely) and whether the parcel's "old" webpage remains intact.

I see this several places in this thread, but I really think it's backwards, and from a quick test I just did in-world, I'm pretty sure it works the other way 'round: the *first* parcel selected when joining seems to have its name and description retained in the joined parcel. Other settings get messed with, it seems (notably, in my experiment, Auto-Return got set to 0--the one setting I actually care about preserving, usually). I'd be real interested to know, first, if others can confirm this (or if it's either a fluke or just random chance), and second, if the parcel retains the UUID of the "favored" parcel (in my experience, that first-one-selected).

I'm not thinking of a way to determine parcel UUID from a script, and don't really have the patience at the moment to wait for Search to update test Profile Picks to see which one survives, if any--but I think Phil is kinda doing that test now.

Hey everyone. I've been researching this issue since it was brought up yesterday, I apologize for not posting sooner.

I have spoken with our search team and they believe what happened is that when you change the boundaries of your land parcel, it changes the parcel ID that is listed in search. Since the parcel ID is changed, the page also changes, which of course means that other references to it are no longer valid. This new issue has been opened as a bug internally, as we investigate preventing this from happening when you "join" additional land to a parcel. We realize this is a serious issue and will continue to investigate it and determine the best solution.

In the meantime, I would encourage anyone who is impacted by this bug to contact the people who currently have your parcel/business added to their top picks (you can find this by searching the All tab for your parcel name and noting the avatars who have listed your store in their picks) and asking them to re-add you. I know this is a clunky workaround and apologize that it is the best one I have at the moment.

Also, I will be posting a blog with various tips for the new search later this week, which should help shed light on how the new all search works.

I would also encourage anyone who is looking for tips on listing their parcel to watch Torley's Tip of the Week video which featured this topic:
http://secondlife.com/showcase/blog.php?blog_category=6

For some odd reason I keep thinking that the amount of selected land on each parcel makes a difference as well.

Would you mind trying again? Select only a few m² of the first parcel and then a big chunk more of the second parcel. If you're right the first one wins, if the selection rectangle makes a difference it should consolidate to the second.

Yay, thankies Jeska .

Thank you very much for responding, Jeska. It's great knowing that you are listening to our concerns and taking them seriously. Kudos to you.

Hooray, Jeska! Thanks for looking into this for us! This will have a HUGE impact on all business owners.

Well, I tried and tried, and now I find that if there's a real rule to which parcel wins, it's beyond me to determine what that rule may be. It seems to be that the larger parcel is more likely to have its name preserved, but not quite always. Other factors I tried: It's not the order in which the subdivisions are selected, not the order in which they were created nor named, not which one if any I'm standing on, not the specific names used, and not the relative sizes of the areas under selection... 'tis a mystery. It doesn't seem to be truly random because probability of win sure seems correlated with relative parcel size, but there was at least one exception, so... I guess I give up.

Maybe, if we end up writing a JIRA, it could go something like this:

"When combining parcels, retain the UUID and name of the LAST parcel selected, just as when linking prims."

It should probably also include a rule for separating parcels also. I don't know how to word it, but someone will come up with something.

Many thanks for posting, Jeska, and thank you also for opening it as a bug. It's appreciated.

When setting up the test, I did a quick test to see if the last selected parcel is used for the resulting parcel's data, and it was, but it seems from all the other tests that it's not reliable, and is somewhat hit and miss.

Until the search team work something out, it's best not to add to, or divide, land when it's search rankings are important, as there seems to be no way of keeping them.

In light of Jeska's post, I'll abandon the test, as it seems that changing boundaries simply creates a new page, and the value of all IBLs are gone for good.

massive, massive ouch.

I know But we do know what happens now (and it's not something that's irretrievable), so this thread was well worth having.

The pick link needs to be smarter than that, though. Maybe the pick link needs to point to a coordinate where the link was set, and not a parcel UUID, and then grab the UUID from there. Precisely because parcel boundaries may shift, the picks should go with the flow and point to that coordinate. For enlargement's sake, it should at least allow you to join land without losing all the links.

That would work fine, as it gives the user the ability to choose which parcel's page to keep intact. It would be a lot easier for them to do than try to change the links that point to a new page. It's necessary for the user to have a way of stating which parcel's page to retain, and that method would do it.

Another way of giving that ability would be to set only one parcel to show in search, and the others not to show in search, and the one that's set to show is the one that retains its page after they are joined.

They do point to the coordinates where the picks were set, and they still work when using them to TP to the place. It's only the html page that has changed - the old one no longer existing. The links in the profile pages still exist, but they link to a page that doesn't now exist, so they are not counting as IBLs for any page/place.

They could think in terms of fixing the links to point to the new page, which would have the added benefit of keeping Picks tidied up. It would mean running a programme each time a parcel changes size, which is probably a lot of times each day. The simpler way, imo, would be to retain one of the original pages - the one that the user determined.

What I inelegantly said was that they should change the way the pick link itself generates a reference that is gathered for the html page, so that the link potentially generates a page to the parcel no matter what the parcel boundaries are.

Parcel A is 512 m and goes from 0,0 to 16,20. Customer B makes a pick at 5, 6. Parcel A now expands to 1024m by joining adjacent land. Customer B's pick still is valid because it makes a link based on the coordinate, not the parcel uuid. The link is not primarily dependent on the parcel UUID, it is primarily dependent on the coordinate. If Parcel A is subdivided and 0,0 to 16,20 is sold, the link will only appear in search if the new owner puts the plot of land in search. Of course, it may have the wrong keywords but the link would still exist, much like how it does now. This way a pick is always functional, even if the coordinate's point changes ownership, and never points to No Parcel.

Phil a couple of things i have discovered in the last few days...somewhat by accident. I have only scanned this thread so i apologize if i am repeating known info. I recently worked on my own land descriptions and titles. All of a sudden i had a ton of sales and didnt know why. It finally dawned on me that i had added a few key words to the actual title/name of my parcels and my traffic and height in the all search list has gone up dramatically!!! Who knew...LOL I also used the fact that i have 3 parcels that i have not joined and listed each with the bulk of the info and key words the same, but changing just a few in each parcel description. That way i can actually include some less searched key words for items in my store, but still get the repetition of the majority of the words....and let me tell you...this has WORKED! Take a look at my land listings to get an idea. Instead of jojo's Folly - furniture and more, etc.....i now have jojo's furniture, blankets, stained glass, etc in the actual TITLE. my store is still named jojo's Folly in world, but for search purposes the words in the title seemed to weighted very very heavily in the search process. For all of you who know the technical reasons, etc...thanks, but i dont need the info...LOL All i know is im selling like crazy!!!!

Phil feel free to im me if you want me to take a look at your listings...im happy to give you feedback. btw...i also listed individual products with descriptions in my picks and those come up pretty high as well. It seems to me that the greater number of titles with your products of ANY kind puts you higher in the all search which is all i care about.

Also, i know why people are using all search so much...i can type the name of something i am looking for in places or classifieds and get no results or just a couple. If i type the same word in all search i can get pages and pages of really good info and i can find what im looking for.

Good luck guys!!!!

jojo

I misunderstood, Cristalle. You are right. That would be a great solution, and it might be very easy for them to accomplish.

There's another bit of info that I've just seen. The original page isn't actually deleted, though I don't know why not - I see no reason to keep adding to the number of useless pages. Darnit, my original ranking page still exists. I want it back! lol

We don't need a PJIRA issue if there's one on the internal JIRA now thanks to Jeska .

You wouldn't need something new: there's already something that regularly pulls inworld profiles and converts those to an HTML page for GSA to index.

It could be that looking up a parcel's UUID's from a Region/X/Y is "costly" and whoever coded it assumed that the UUID would always remain static as long as the location of the pick hasn't changed so skipped revalidating each pick on every update and simply uses a cached URL.

If every picks' URL is simply revalidated each time the web profile page updates then everything can stay the way it is. Profiles seem to update daily so you'd still loose your ranking for a short time intially, but as each profile page updates it'll point to the new parcel URL (you loose your traffic when you join parcels together as well, so that would at least be consistent ).

Anyway, none of us knows enough of how it all works behind the scenes to suggest "solutions" that would actually be of any use .

Considering that picks can sometimes be completely irrelevant to the parcel, there is no point in revalidating until they separate location picks from personal picks. As Sansarya's example noted, you can find Canimal by searching for Mulch (her friend, Mulch Ennui).

Hi Jojo. I'm very pleased that you're doing well in search, but this thread isn't about that aspect of search

Before I joined the parcels, I did consider not joining them, and using their names and descriptions in the way you described, but I decided in favour of increased traffic instead. On the one hand, I would have been better off if I'd decided against joining them, but on the other hand, we've all learned something important from joining them - including LL

So true. But they could find our suggestions to be very useful as they consider what to do about it.

Quite so. But I'm pretty interested in the details of how this all plays out, for a couple of tangential reasons. First, it's essentially impossible for a script to tell if two points are over the same parcel. (The script can make a reasonable guess, if all the parcel details are exactly the same, but a freshly split-in-half parcel will look identical on both sides of the split, as far as a script can tell.) So I'd really like there to be script access to some unique identifier of the parcel, and as we see here, that very identity isn't well-defined--or certainly not intuitive.

Second, a different tangent: despite the fairly phenomenal success of the adfarm ban, I still kinda suspect that some parcel-to-parcel "muting" will be needed eventually--if not for adfarms, then for screening age-restricted parcels. And one thing I always secretly worried about was how to preserve the identity of parcels on a mute list, in some way that's consistent through joins and divides and (possibly bogus) transfers.