[Suggested Followup project to Marketplace Beta Search] VMM based [Group] Listings~

[Polymath Snuggler]

VMM based [Group] Listings- Getting 6 birds with 1 (really big and kind of complex ) stone.

Ohhhkaaaaaay so:  I made a JIRA Feature Request.

 

It's long winded.  It's detailed.

And it's not that technically difficult to implement ~ (as best I can tell anyhow!).

It's just menial and has a lot of steps to it.

But it's technologically doable within the confines of the present system.

 

 

Below is a text of the JIRA ticket.

 

Marketplace Groups / Variant Listing Handling:

I propose making marketplace "Group" listings. ( Note these will be Opt in! No retroactive updatery required! ) The combined / fixed relevance from associated items should be sufficient attraction for merchants who actually care to go fix their listings.

It starts inworld on the VMM side of things~ in the MP interface. Add a new type of folder to the folder hierarchy. "Group Folder" Any Folder added to this will automatically tell the system to handle the following listed items within the folder as a [Group] .[Group]ed items may share mesh bases, or from the same gatcha event or whatever the merchant deems their linkage is. Any contained ACTIVE listings will be fed into the [Group] and accessible via the marketplace store interface.

The group folder should automatically create a single sub-folder with the word "DEMO" in it~ this should be the group folder name + [ DEMO ].

On the website side of the equation the group listing must be handled in a special manner.

Every listing inside a [Group] MUST BE PRICE LOCKED to the group listing. Whatever the [Group] price for the item is, that's the price that gets set to every single active listing in that folder. This is to prevent marketplace gaming of gatcha Rares into groups of gatcha dregs. etc etc. A group of items inherently, by definition is all the same and identical in the merchants eyes. So they MUST all be sold for the same price. This is important for this next part to work.

The checkout buttons for groups must have additions



The  [Group] Header listing will have a "Buy All" Discount Dropdown/ Rollout Menu where the merchant can select 10%, 20%, 30% etc discount. This will allow the merchant to specify a flat discount rate for if the customer chooses to buy the whole darn thing. This needs to be a posted value on the listing. ( again see reference image ) Just make sure the group buy-all discount percentage requires 2 or more listings in the group to be marked as Active.

This  [Group] Primary listing requests the merchant to choose an item from the folder to be the main listing. ( Statistically probably the black one ) A [Group] cannot be set to Active without a primary listing. The merchant then fills in all the appropriate fields for that listing and here's another important part: At the bottom of the listing entry. There should be two choices. "Save listing" "Save Group" Save listing edits the singular listing. "Save Group" should automatically copy that entered data into the rest of the listings in the group except for changing the listing title ( that should be the listing folder name anyways ) and the sold item. This leaves individual listings to be manually edited if the merchant sees fit however any price changes to any entries must either be greyed out or trigger a [Group] wide price change.

Automatically appended folder that contains the DEMO item should light up the DEMO button if and only if there is an Active DEMO listing in the group designated DEMO folder.

Section 2: Appending & Updating old listings.

A merchant creates a group folder: It auto appends it's default [ DEMO ] folder but remains empty.
If the merchant attempts to drag & drop another listing ( Active or Inactive ) into the folder it will popup a dialog message.

"Warning!! You are attempting to append this listing to a Group. This will merge this listing into the group listing and set this listing to [Inactive]. THIS OPERATION CANNOT BE UNDONE!!!!"
[ Proceed / Deny ]

Likewise if a merchant goes to remove a LISTING folder from a [Group] that has been set to Active, they will be prompted ( again big loud warning message ) that they will lose all associated sales statistics from that listing. The listing will remain "filled out" but it will lose all of it's search sales & relevance statistics. And the group listing will have those statistics removed from the overall listing.

If the merchant accepts the listing data and associated search relevance statistics should be appended and merged into the group ranking. The appended listing should be temporarily downgraded to an Inactive listing. Obviously if LL chooses to internally store that data separately anyways that would plainly be a prudent choice. But willy nilly grouping and ungrouping of items I feel would make the system exceedingly gameable ~ especially with merchants "grouping" their best sellers with their new items and or some other wierdness.

A listing should now be a categorical [Group]. When the [Group] listing is made active and the page is visited the ALTERNATE variants of the  [Group] items should be listed across the top of the page , much like the current "Promoted advertisements" system presently does. Selecting any of them will bring you to the sub-listing page. Note: The checkout should still have the "BUY ALL ITEMS" option there at all times regardless of what sub-listing they are on.

 

How this solves things

Each created listing as it presently stands has it's own relevance rating, it's own sales popularity and the only "group" effect that elevates overall relevance priority is average store success. It's exceedingly difficult to track conversion rates, demo sales, and overall product success. It's also exceedingly difficult to categorize and track disparate rankings~ especially when your DEMO is your best seller ( not often but it happens )

The inclusion of this system would create a non-gameable condensed set of listings. The updated listings will gain "traction" and boosted relevance in the search algorithm due to condensed sales statistics which will encourage merchants who actually care to update their marketplace listings. Yes it's a lot of work. But again between the automated updates of entire categories of items as well as better searchability and relevance. If the merchant cares enough. It's worth it to them. They'll do it. This self balances out listings that no one cares about ( their relevance will drop over time and they'll remain disparate entities ) and these grouped listings will take search priority. However, people who attempt to 'game' the system by putting their entire store into one search ranking will also run the incredibly high risk of being reported and having their ENTIRE inventory de-listed in one single fell. (Remember grouping 'cannot' be undone!!) Grouping items illegitimately poses a serious risk to the vendor. I think abuse of it will be very low if the outlined rules I posted above are put in place.

The benefit for the community is more impulse purchases of grouped content at discounted prices.( anyone who's seen a 'fatpack' vendor knows full well how important this is to sales )

It removes Marketplace Clutter and improves overall relevance by condensing identical items into a single search return.

It removes Marketplace Clutter from DEMO items, but still preserves sales ranking from pre-existing DEMO items that are currently 'carrying' a listing.

It improves overall statistics return on viability of products and conversion rates.

It makes Selling marketplace ads more profitable for everyone.

It makes listing multiple items quicker and easier for merchants. As well as updating those items.

For all I know LL this is phase 3 of the whole VMM> Marketplace Beta Search > Grouped Listings marketplace overhaul they've been planning all along. Though on the off chance that wasn't the case. Here's the post to make it happen.

Sincerely - Your commerce community. ( And ~ Me! )

[Darrius Gothly]

I'm going to have to take a few stabs at this to add my input in any meaningful way. I think you've got a good start, but there are some conditions you've added that I think could use some expanding, and some that don't need to be imposed. (And for starters, you aren't the only one that turns Forum Threads into JIRA's 8^P LOL)

A concept like a Group Folder walks hand-in-hand very well with a feature they added a few years back: Linked Items. A Linked Item can be added to a folder as only a virtual link to the original item. That way you can include NoCopy items in multiple folders, most commonly clothing and outfit folders. (like my really cool glasses that are NC but fit so well with all of my outfits and ensembles.)

I think the features of a Group Folder should stop approximately there. The other features and attributes that you've included in the basic definition apply, but only in certain cases. However the concept of Grouping is applicable everywhere and to all situations.

As an example, I sell a few "Packs". Those are products that are really just collections of other front-line products. The packs sell for a reduced price .. and setting that is easy. But updating and maintaining turns into a nightmare because I have to not only update the primary product, I have to go disassemble each Pack and reassemble them with the updated primary product replaced. That not only means I have to redeliver the entire Pack to prior purchasers (even when only one sub-component was updated) and there is no DIRECT LINK from the Primary Product to the Pack that contains it.

By making a Group Folder hierarchy that stores only Virtual Links to the primary components, giving that Group its own Product ID and Pricing, but retaining full record of the parts that were included .. it becomes a much easier task of updating when one of the components must be updated. It should also be reported in the Sales Notice as a "Group Sale" and each component should have its own line item detail. The final total from which commissions are calculated can then be shown after the individual line items along with a percentage or fixed discount for the entire Group Purchase.

As I said above, I think you're on a good path here .. but you may have gotten a bit too specific in the definition. I can envision situations such as mine where a Group equates to a "Fat Pack" (or similar) as well as those places where a Group could be an entire ensemble of fashion parts .. and where the customer can click to visit individual parts or just buy the whole thing in one transaction. Really the mechanism itself is very flexible, so adding restrictions based on contents or pricing would sully that power and lessen flexibility.

Now .. would you like the historical database on how many years we've been asking for this? Or should I leave it to you to go dig up? *GRIN*

[Darrius Gothly]

To the best of my knowledge, no in-world Vendor System provides a capability similar to this. I'm not very well schooled in the full capabilities of all in-world systems, so I'll ask for anyone else to contribute their experience/expertise here. But usually I've noticed that features provided by in-world systems are things we most often want to see in Marketplace as well.

Perhaps if we can find a working model in existence .. that can serve as a base or platform on which to build a richer feature set .. we can more easily "Sell" this idea to LL and the Commerce Dev Team. If they can go touch, operate and study something already working, the chances they'll see our need become even better.

As for Demos: Some things just do not need or don't really lend themselves to Demos. Having the Demo hierarchy enforced at the start would be somewhat off-putting to many folks. A basic listing page is confusing enough to many; having to fill in (or even worse, ignore) things on the page would add just too much noise to many people's decision tree. I'd agree with an easy Demo Link function, but not something that insists or even strongly encourages Demo Items.

And as an after-thought, Group Folders could be marked as "Organizational Only". That would mean they are not sold as a combined purchase, but instead lead to a subset of listings that are all related by some conceptual attribute only. (Outfits in a range of colors or sizes for example.)

And THEN we'd like the ability to include items from other's stores. Creators and Merchants that are in league with each other (or are Alts of the same person) could then be combined into more complete "Customer Solutions" such that one purchase gets you all the clothing, accessories and doo-dads that go into making one complete look. How you approve the inclusion of your items in someone else's Group? That's a whole 'nother question. But while we're slaying giants ... *grin*

[Polymath Snuggler]

I clarified the one sentence in the JIRA pretaining to Group Demos.    I wanted the group to be an ironclad catagory for variants of the same product or same product line ( equal value )  Such as all the commons from a Gatcha Console.

 

In that sense the overly detailed specifics was completely intentional.   "Loose collections of items" are already handled by the "related items" tab at the bottom of the marketplace.

 

The idea is that the [Group] itself shows up as a listing of the individual item copy in it ~  IE the listing shows up in search as 395 L$ in the example I provided.

The intended spec in this case is single item vending of color / texture / design variants of a single entity.  I managed to eke Gatchas into the form ~ but I'm... hmm ~  will think about it.

[Polymath Snuggler]

The VMM already handles updates to listings.  You can plug any item you wish into a listing folder and set it to Active and it will sell that item.   The proposed Group Folder would house Listing Folders which each contain associated items.

 

Anything with tiered heirarchy winds up being rather difficult to explain in paragraph form.

[Darrius Gothly]

---

polysail wrote:

I clarified the one sentence in the JIRA pretaining to Group Demos.    I wanted the group to be an ironclad catagory for variants of the same product or same product line ( equal value )  Such as all the commons from a Gatcha Console.

In that sense the overly detailed specifics was completely intentional.   "Loose collections of items" are already handled by the "related items" tab at the bottom of the marketplace.

---

Hmm ... Related Items are a bit too loose for me.

A lot of what computers do best is keep records of what happened. It's just a shame when the computer (in this case) does all the "what happened" stuff AND then doesn't let you have easy access to those records.

The Group concept is very pliable and can be useful in many ways .. much like the "Box" concept survives even with VMM and Folder Delivery. Applying it to improve sales, product acceptance and usability .. all while providing easily used transaction records? That would be a major win-win in my book.

I'm proposing that with a small bit of leeway, your exact goal can be achieved without sacrificing other benefits at the same time. You can utilize a slightly broader scope tool to get the same effect you seek, while others can pick up the same tool and achieve a different but equally desireable outcome. Kind of the difference between a hex-head wrench and a spanner. I'd rather have a well made spanner than some larger number of fixed-size, fixed-use wrenches.

[Darrius Gothly]

I sell three products: Box A, Box B and the most popular Box Z. I also sell two Fat Packs: One with Boxes A and B, and one with all three A, B and Z.

When I release an update to Box B, I can quickly pull records that show me who purchased Box B and send them an update. (Albeit manually, it's still mostly there for me to copy or import.) But what about those that bought one of the two Fat Packs? How do I find them and what do I send them?

If the Fat Packs were Group Folders, folders that contain only virtual links to the components, a report showing who received Box B would also include those that purchased the Group/Fat Pack products too. Then my list would be complete, and would not require me to also pull and merge separate reports for each Fat Pack.

I also know I only have to send them the updated Box B. That's the product they really received; the Fat Pack is just a handy grouping construct that isn't a real product. So updates to a real product result in sending .. the real product updated. Again there's an economy of activity and also a level of organization that reduces confusion among the customers. Because they only receive an update to the part that was updated, they are never unclear on "Which Box A is newer? Or are they the same? or .. ?"

[Darrius Gothly]

Further thinking on Related Items usage:

If I understand you correctly, you advocate using them to list the components of the Pack. So that someone looking at the Pack listing can easily click to go to each component's product page.

But I'm left-handed .. and I want to use the Related Items to show off the other products in the line that are NOT included in the Pack. That way I can leverage interest in the Pack to upsell into other products as well.

Ketchup .. or Mustard I guess.

[Polymath Snuggler]

No the "Pack"  / Group listing when you pull it up will look like this ~

In the multiple search results window it looks like a normal listing with a normal listing price ( In this case 395L$ )

 



 

The similar pricing is to fill out the entire field quickly.  You are correct though that there are "groups" of items that all go together that may be of varying prices. Like this entire shop for example.

https://marketplace.secondlife.com/stores/49727
Is a grouping nightmare.

 

But the goal of this is to condense mutiples of identical listings into one collapsed entry and have them ALL show up in a single search~  ( with a single listing price )

[Darrius Gothly]

(I am sure there are people on the forums that have just whispered to themselves "oh no .. she didn't open THAT subject with him .. did she?" LOL)

I still maintain that the ability to group items that vary only in one or just a few attributes .. will never work. More to the point, HAS never worked. Not on platforms rigged the way Marketplace is. I won't belabor the reasons as there are many who have heard it all too many times. Just know that .. been there, watched it fail .. still have the t-shirt.