Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-10853] [Marketplace / VMM Experience] VMM Folder Heirarchy Changes. Added Support for Item Groups & Group Demos #1139

Open
1 task
sl-service-account opened this issue Dec 3, 2015 · 5 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Dec 3, 2015

How would you like the feature to work?

I understand a 'concept' such as this has been previously stated in BUG-6424. However this idea expands upon that drastically. It's a general consensus of a very long forum community thread. I'm just apparently the only one who takes forum threads and turns them into JIRA tickets. [meh!] Okay~ on with the show!!

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 Listing Folders will be fed into the [Group] and accessible via the marketplace store interface. As the group is set to [Active] or [Inactive] all contained listings inherit this property.

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 entire Group Listing Will show up in search results with the Locked Price for the listing. IE the listing contains 8 color variations that each sell for 395L$ ~ the listing itself shows up as 395L$. There might be some sort of manner of differentiating a "Multi" listing from a single item one. Such as putting a fancy border around it or something to denote "more inside".

The checkout buttons for groups must have additions {See uploaded image} 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. Otherwise the DEMO button should not exist in the button array or be greyed out.

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]( 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 weirdness.

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.

Why is this feature important to you? How would it benefit the community?

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 older listings that no one cares about ( their relevance will drop over time and they'll remain disparate entities with their own individual sales statistics) and these grouped listings will take search priority with their more cohesive relevance. 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.

Posting of multiple similar listings in one go. Creating multiple listings for 2-15 variations of 1 object ( particularly fashion items ) is staggeringly time consuming at the moment. Reducing that will bring a LOT more of the fashion designers that sell "in world only" onto the SL Marketplace. This tedious task of creating 15 different ( even with the fill in data feature ) listings then trying to make them all "related items" to one another has kept a LOT of vendors off the web service.

It makes large discounts for bulk purchases possible and more clearly visible for the customers. This has long been a staple of inworld commerce. Bringing it to the SL Marketplace will help sales volume drastically. A lot of people impluse buy "fatpacks".

Retention of prior sales statistics ~ including Demo sales statistics. So prior "interest" in an object is still preserved under the new system. Condenses and improves overall relevance results.

It improves product statistics on viability of products, product lines and conversion rates for the merchant.

It removes Marketplace Clutter and improves overall relevance by condensing identical items into a single search return. (An age-old community request)

It removes Marketplace Clutter from DEMO items, but still preserves sales ranking from pre-existing DEMO items that are currently 'carrying' a listing. (Another age-old community request)

It makes selling marketplace ads more of a profitable venture for everyone.

It improves store presentation. Which improves customer shopping experience and aids in their decision making process. As a merchant I want my customers to be choosing from product A and product B, both clearly different. Then I want them to decide "I like the red one and the pink one.. jeez decisions decisions!![ Oh but this one has butterflies on it too]( Oh but this one has butterflies on it too)" Note: They've already decided they like the product at this point. People make purchasing decisions in set patterns.

For all I know LL this is phase 3 of the whole VMM> Marketplace Beta Search > Grouped Listings marketplace overhaul you'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! )

Attachments

Links

Related

Original Jira Fields
Field Value
Issue BUG-10853
Summary [Marketplace / VMM Experience] VMM Folder Heirarchy Changes. Added Support for Item Groups & Group Demos
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Created at 2015-12-03T13:38:39Z
Updated at 2017-05-08T23:50:19Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2015-12-03T15:12:35.647-0600',
  'How would you like the feature to work?': 'I understand a \'concept\' such as this has been previously stated in BUG-6424.  However this idea expands upon that drastically.  It\'s a general consensus of a very long forum community thread.  I\'m just apparently the only one who takes forum threads and turns them into JIRA tickets.   [meh!]  Okay~  on with the show!!\r\n \r\nMarketplace Groups / Variant Listing Handling:\r\n\r\nI 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.\r\n\r\nIt 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.\r\n\r\nThe group folder should automatically create a single sub-folder with the word "DEMO" in it~  this should be the group folder name + [ DEMO ].\r\n\r\nOn the website side of the equation the group listing must be handled in a special manner.\r\n\r\nEvery 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.\r\n\r\nThe checkout buttons for groups must have additions {See uploaded image}   The [Group] Header listing will have a "Buy All" Discount Dropdown.   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.\r\n\r\nThis [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.\r\n\r\nAutomatically appended folder that contains the DEMO item should light up the DEMO button if and only if there is an Active DEMO in the group folder.\r\n\r\nSection 2: Appending & Updating old listings.\r\nA merchant creates a group folder:  It auto appends it\'s default [ DEMO ] folder but remains empty.\r\nIf 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!!!!"\r\n[ Proceed / Deny ]\r\n\r\nIf 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.\r\n\r\nA 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.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': '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 )\r\n\r\nThe 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.\r\n\r\nThe 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 )\r\n\r\nIt removes Marketplace Clutter and improves overall relevance by condensing identical items into a single search return.\r\n\r\nIt removes Marketplace Clutter from DEMO items, but still preserves sales ranking from pre-existing DEMO items that are currently \'carrying\' a listing.\r\n\r\nIt improves overall statistics return on viability of products and conversion rates.\r\n\r\nIt makes Selling marketplace ads more profitable for everyone.\r\n\r\nIt makes listing multiple items quicker and easier for merchants.  As well as updating those items.\r\n\r\nFor all I know LL this is phase 3 of the whole VMM> Marketplace Beta Search > Grouped Listings marketplace overhaul you\'ve been planning all along.   Though on the off chance that wasn\'t the case.  Here\'s the post to make it happen.\r\n\r\nSincerely - Your commerce community.  ( And ~ Me! )',
}
@sl-service-account
Copy link
Author

Darrius Gothly commented at 2015-12-03T21:12:36Z

I can't really support the idea of Price Locking the components of a Group Folder. That seems far too restrictive. It prevents use of the feature in so many other cases where it could be very beneficial. I will support some form of "Clearly Visible Pricing" so that the individual prices for each component are clearly shown. That would seem to reduce the probability of loading up a Group with one gem and 100 stinkers. (If I understood the goal of that requirement correctly.)

@sl-service-account
Copy link
Author

Darrius Gothly commented at 2015-12-03T23:30:38Z

The improved graphic does help me comprehend the intended goal a bit more. There still seems to be a gap between the individual parts contained within the Group, their prices .. and the overall cost. Is there some way to easily and directly display that info that won't overload the screen too? If a method can be found then I'd have a lot more ease understanding what is going on with the listing. Visual cues, such as the extra "Pack" purchase buttons on the right, add to comprehension and understanding. It just "feels" like the pricing info is of high enough importance to be included on the surface view too.

@sl-service-account
Copy link
Author

Darrius Gothly commented at 2015-12-04T13:24:47Z

I'm liking it more. The additional detail in the Variations Slider helps a lot. I can assume the appropriate arrows and widgets to scroll when more items are present, etc. I need to sit down and walk through the mechanics you've laid out; that will take me a bit more time. But I do like where this is headed. (Now if we can get others to see, sign on and promote this idea...)

@sl-service-account
Copy link
Author

polysail commented at 2015-12-04T13:26:23Z

Updated Infographic to be even clearer.

@sl-service-account
Copy link
Author

polysail commented at 2015-12-04T15:16:04Z

Edited listing description explanation slightly.
Edited "How will this help the community" section to be more clear.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant