LL updates on listing enhancements

Update 5th October: Please read here for a further update on the listing enhancements situation, and the Marketplace in general.

Following recent updates with listing enhancements, as reported on this blog earlier this week (Run silent, run deep: the SL Marketplace and eroding merchant trust), the Commerce Team have issued the following post on the Merchant’s forum:

SUBJECT: PLE Update

Merchants,

As some of you are aware, we have been giving away free listing enhancements to many of you for the past 2 months. We recently deployed a fix that was supposed to just start billing again. Unfortunately, it back-billed the free enhancements. We apologize for doing this without warning.

To show our appreciation for your patience with this mix-up, we will be doing the following:

  1. Giving everyone free listing enhancement renewals* for the period between August 7, 2012 and today. This means all listing enhancements billed during this time will be refunded before end of day today (October 4, 2012).
  2. Once the refunds have completed, we will begin billing those enhancements again.

For full details of today’s release, please see the Marketplace Release Notes on the wiki.

Thank you for your patience.
The Commerce Team

*If you created a new listing enhancement after August 7, 2012, that listing enhancement is not eligible for this refund.

While it is interesting that the post presents the suspension of listing payments as being a part of a “free  listing enhancements” offer – an offer merchants appear to have been unaware was actually being made (I also can’t remember having seen any notification, but then I could easily miss an elephant walking by unless it happened to tread on my foot in passing).

There has been some connection between my earlier post on the matter and the above announcement from LL. While I’m sincerely flattered that such connections have been made, I’m nevertheless sure the timing was little more than coincidental.

Hopefully, once the round of refunds has been completed, this matter at least can be pout to bed where the Marketplace is concerned. Hopefully, there will be more communications on the status of the remaining issues in the near future.

With thanks to Toysoldier Thor for notifying me of the LL forum post

Run silent, run deep: the SL Marketplace and eroding merchant trust

Update October 4th: Linden Lab have issued a forum post on this matter, please see LL updates on listing enhancements.

Linden Lab depend on land tier (server space, call it what you will) for  80%(ish) of their revenue. This places them in an awkward position vis-à-vis providing any form of tier easement, even if they wanted to (as I’ve commented before).

The remaining 20% comes from the likes of Premium membership, and more particularly, the SL Marketplace (SLMP). In the case of the latter, the revenue doesn’t only come from the 5% commission on goods sold through the Marketplace, a lot of it comes via the listing enhancements merchants are encouraged to pay for. These theoretically boost sales by placing items in places such as the SLMP home page, or on the Checkout pages, and are paid for on a 30, 15, or 7-day rolling subscription basis, costing merchants between approximately $5.00 and $12.00 USD a month per item, with some merchants paying over $200 USD per month for enhancements.

Listing enhancements – can amount to a pretty penny in outlay per item

Earlier this year, the system went haywire, failing to take due subscriptions for around a two-week period (JIRA WEB-4638). It was finally resolved by Linden Lab taking a single, large payment from merchants’ accounts. While people had no issue in paying for services rendered, the problems here were that a) next to no forewarning was given that accounts were about to be so debited, leaving many merchants with a sudden and unexplained drop in their account balances; and b) many were billed in excess of the two weeks subscriptions actually owed (with some reporting being billed for up to four weeks); while c) the billing information received made it hard for merchants to actually determine which of their listing enhancements had been billed, or even if the right enhancements had been billed.

This understandably led to some confusion within the merchant’s forum, and not a little upset, particularly as some merchants had also been faced with an inability to cancel some of their listing enhancements due to an ongoing issue with many items remaining stuck in a “locked” mode, preventing them from being edited – a situation itself which at the time was some 18 months old (and is now some two years old, and still awaiting resolution – see WEB-2974).

While merchants were refunded for any overcharging on their account as a result of the billing issue, the manner in which the situation was handled by LL resulted in something of a drop in trust where the Marketplace is concerned, and a number of merchants publicly indicated they would be ceasing in their use of enhanced listings.

At the end of July, the problem started again, and was raised as a topic for discussion in mid-August, as well as having a new JIRA (WEB-4927) raised against it. Neither the discussion thread nor the JIRA drew comment from the Commerce Team. Instead, a single payment was taken from all “at fault” accounts, again without any forewarning, and again with Merchants facing issues over what, precisely, they have been charged for, and whether those listings they have made payment against are actually active.

Failed subscriptions for August – courtesy Ry0ta Exonar

Again, the problem here is not so much that things Went Wrong and broke again – that’s pretty much taken to be the standard operating condition for the Marketplace nowadays – but how the Commerce Team managed the issue. Almost nothing was said on the matter (again), with the only communications forthcoming from the Commerce Team being a terse instruction not to re-open WEB-4638 after Ry0ta Exonar attempted to do so (hence WEB-4927), and a brief Marketplace dashboard message posted on September 28th, which simply said:

We are aware of some issues with Product Listing Enhancements. Keep an eye on the Grid Status page for more details.

With neither the dashboard message or Status page message actually stating what was about to be done.

So is it little wonder that merchants are again looking at listing enhancements with a jaundiced eye? Several have re-stated the fact that they will no longer participate in the process and others have stated they are terminating – either automatically or manually – their subscriptions. Given that LL are seeking to increase their non-tier related revenues, one would think that ensuring the one service which does so is run with a level of professionalism and communication that would not undermine customers’ faith in the service, or their willingness to place money into it.

Currently, and added to the rest of the ongoing litany of issues and problems with the Marketplace, this doesn’t appear to be the case.

Related Links

Marketplace issues: September update

On September 20th, Commerce Team Linden provided a terse update to the ongoing problems related to direct delivery. The Update reads in full:

The transition from Magic Boxes to Direct Delivery has been extended indefinitely. We will be providing a 30-day warning before any shutdown actions are taken and will avoid doing this before peak holidays for the Marketplace (Halloween, Christmas/New Year’s, Valentine’s Day).

We are aware that some Merchants are still having problems with the Merchant Outbox. We are are working with TPVs and our internal development teams to address this issue.

The comment relating to TPV involvement possibly relates to  WEB-4600, VWR-28630/VWR-28631 and VWR-28629, although it has caused some confusion, as there appears to have been little or no recent discussion on matters between LL and at least one TPV team.

The update gives no further information on the status of the range of JIRA items related to the Marketplace which have been under investigation now for the greater part of 2012. These items comprise:

  • Limited Quantity Support Merchant does not have rights to copy the items for sale (no JIRA number supplied)
  • WEB-2974 (Listing enhancement stuck in “Charging, cannot edit right now” state)
  • WEB-4138 (Confirmation emails failing to deliver)
  • WEB-4441 (Orders stuck in “Being Delivered” state)
  • WEB-4554 (Test delivery permissions incorrect)
  • WEB-4567 (Bulk delete fails for some merchants)
  • WEB-4587 (listings with the wrong images)
  • WEB-4592 (Orders marked as “Delivery Partially Failed” on success)
  • WEB-4600 (Merchant Outbox failures)
  • WEB-4696 (Deleted listings appearing in search results)

Meanwhile, in the Marketplace release for September 26th, 2012, the Commerce Team did successfully change the “sent from” from email address to service@mail.Secondlife.com for all sales notification e-mails sent to merchants (this was previously no-reply@marketplace.secondlife.com). However, as no formal notification was apparently given on this change ahead of time, many merchants only discovered the change as a result of their e-mail applications treating incoming sales notifications with the new “from” address as spam …

Virtual Landmarks: solving an age-old problem?

On July 24th, Toysoldier Thor posted about an idea he calls “virtual landmarks” in the Merchant’s forum. It’s a potential solution to an age-old problem most of us in SL face at one time or another: making sure all landmarks relating to your location in Second Life are always up-to-date.

Whenever we move in SL, we’re faced with the fact that every LM we’ve ever given out for our old place is now worthless, and we have no choice but to start issuing new ones. For some, this isn’t a problem – but for others it very much is.

Merchants, for example, are faced with the fact that every single landmark they’ve ever placed within a package contained in a vendor server or magic box or in a Marketplace folder or used within landmark givers they’ve placed around the grid (at malls, satellite stores and so on), now needs to be individually replaced (and in the case of Marketplace folders, each folder manually re-linked to the relevant listing). For some this can run into several hundred items and many hours of additional work. Nor are merchants alone – the likes of role-play groups, clubs, and so on, can face similar issues, both in terms of updating landmark givers, etc., and in terms of ensuring patrons get updated LMs.

In short – it’s a nightmare.

The issue: change your SL location and old LMs no longer work – click to enlarge (credit: Toysoldier Thor)

Toysoldier Thor’s idea is so elegant and (in some respects) obvious, one is tempted to ask why such a system wasn’t developed for Second Life from the outset. He calls it Virtual Landmarks (VLMs), and it essentially works in a similar manner to how we navigate the web. He describes the idea thus:

The concept of a VLM would be identical to the critically important Internet service of DNS (Domain Name Services) in that Internet users can create and use easy to understand HOST NAMES to access all Internet services where the HOST NAME actually masks the underlying required IP Address that is needed to actually route and connect their computer to that respective host.

Well the same would hold true with VLMs.  A VLM would be the equivalent to a DNS HOST NAME and the LM that is configured to be associated to this VLM would be equivalent to an IP ADDRESS.

One Change

In his proposal, rather than creating and distributing a landmark, a store-owner (or whomever) would create a user-friendly VLM (e.g. “My Wonderful Store”) which is then associated with the actual landmark for the store itself. This association is stored in a new service Toysoldier calls the “VLM Mapping Service”, and it is instances of the VLM – not the original – which are given to people or placed product packages, landmark givers, etc. When someone uses the VLM, their viewer sends a request to the Mapping Service, which  looks-up the physical landmark associated with the VLM and sends the information back to the viewer, enabling the user to be teleported to their desired destination.

The beauty here is that if the underlying landmark is subsequently changed (because the destination store moves, for example), all the creator of the VLM has to do is associate the VLM record stored in the Mapping Service with the new landmark – and every instance of the VLM in existence will automatically route people to the new location when used. There is no need to pass out new LMs, replace existing LMs or anything else; one change, and that’s it.

The solution: VLMs and the Mapping Service – click to enlarge (credit: Toysoldier Thor)

There are further benefits of the idea, as Toysoldier points out:

  • The system could be developed such that a single VLM could be associated with multiple landmarks (such as a primary store location, a secondary store location, etc.). Then, should the primary location be unavailable for any reason, the person using the VLM would be automatically routed to one of the alternate destinations
  • A round robin capability could be included, such that a single VLM is linked to a number of arrival points at the same destination (such as a club or an event that is liable to be popular, etc.). People using instances of the VLM are then automatically delivered to the different arrival points in turn, helping to prevent overcrowding at one particular point
  • Duplicate names could be supported for VLMs through the use of asset UUIDs (so there could be many VLMs called “My Beautiful Store”, and asset UUIDs could be used to ensure a VLM sends a user to the correct destination
  • As with LMs at present, VLMs held within peoples’ own inventories can be renamed without affecting their function
  • The system does not prevent the direct use of landmarks.

While there is some potential for griefing within the proposed system (people maliciously creating an VLM with the intention of flash-mobbing a venue or mis-directing people to a location, for example), the risk is probably no greater than is currently the case with the use of landmarks. Griefing via the use of VLMs might even be easier to limit, as LL would have control of the Mapping Service and so could effectively remove / disable VLMs shown to have been created with malicious intent.

Continue reading “Virtual Landmarks: solving an age-old problem?”

SL Marketplace Issues: July update

On July 31st, The Commerce Team issued the most recent update in the ongoing saga of SL Marketplace issues. The update reads in full:

UPDATE: July 31, 2012

We continue to work on testing the next Marketplace update, which includes a required upgrade (for the Marketplace, not for Residents). One benefit of this work is that we are seeing performance increases with page load and purchase completion during our testing. We are working to get this update completed as soon as possible.

Last week, fixes to help with WEB-4600 were deployed with viewer 3.3.4. We have also been working with Third Party Viewers to make sure they are handling the Merchant Outbox correctly going forward. In addition, some Third Party Viewers now support the Merchant Outbox on Linux. Please see the following Third Party Viewers if you would like to use the Merchant Outbox on Linux:

If your Third Party Viewer is not on this list, and it supports the Merchant Outbox on Linux, please send a notecard to CommerceTeam Linden. Please include a link to the download location, and it will be added to the above list.

Below is the updated set of outstanding issues with Direct Delivery and the Marketplace.

Direct Delivery

Here are the outstanding Direct Delivery issues:

  • WEB-4600 (Merchant Outbox failures): There are still outstanding issues with the Merchant Outbox, in addition to the issues addressed above. We continue to investigate and address these issues as they come up.
  • WEB-4554 (Test delivery permissions incorrect): This is on hold while we work on other issues.
  • Limited Quantity Support (Merchant does not have rights to copy the items for sale): This is currently being worked on. Magic Box migration will not be required until this is supported. (Note that Merchants can sell items that have next owner rights set to “No Copy”.)

Overall Marketplace

There are also several issues that occurred around the time of the Direct Delivery launch that we are still working to address, but are not issues with Direct Delivery.

  • WEB-4587 (listings with the wrong images): This will be addressed after the next Marketplace update.
  • WEB-4441 (Orders stuck in “Being Delivered” state): We have been able decrease the number of orders getting stuck and continue to work on preventing all orders from getting stuck.
  • WEB-4592 (Orders marked as “Delivery Partially Failed” on success): This issue is currently being worked on.
  • WEB-4138 (Confirmation emails failing to deliver): We are currently working on a solution to this issue.
  • WEB-2974 (Listing enhancement stuck in “Charging, cannot edit right now” state): This issue is on hold while we work on the other items on this list.
  • WEB-4696 (Deleted listings appearing in search results): This issue is on hold while we work on the other items on this list.
  • WEB-4567 (Bulk delete fails for some merchants): We will evaluate the priority of this once we have completed the above Direct Delivery fixes and features.

In the meantime, the due date for Magic Box migration has again been extended (as of July 26th) to October 1st, 2012.

Direct Delivery issues: June update

On June 7th, and missed in the build-up for SL9B, the Commerce Team issued a further update on the stains of ongoing work to fix various issues relating to both Direct Delivery and listings problems. This appears to be the latest in what seems to be monthly updates. The latest post reads:

06-07-2012 02:53 PM

Below is the updated set of outstanding issues with Direct Delivery and the Marketplace.

Direct Delivery

The following Direct Delivery issues have been verified, but have not yet been addressed:

  • WEB-4600 (Merchant Outbox failures): We have been working on this issue and will not shut down Magic Boxes until this is addressed. In some cases, logging out and in from the Marketplace and then the viewer may resolve this problem.
  • WEB-4554 (Test delivery permissions incorrect): This is currently under investigation.
  • Limited Quantity Support (Merchant does not have rights to copy the items for sale): This is currently being worked on. Magic Box migration will not be required until this is supported. (Note that Merchants can sell items that have next owner rights set to “No Copy”. Please see the Knowledge Base article on Object permissions for more details on how permissions work.)

Overall Marketplace

There are also several issues that occurred around the time of the Direct Delivery launch that we are still working to address, but are not issues with Direct Delivery.

  • WEB-4587 (Listings with the wrong images): This is currently under test.   
  • WEB-4441 (Orders stuck in “Being Delivered” state): We have been able decrease the number of orders getting stuck and continue to work on preventing all orders from getting stuck.
  • WEB-4567 (Bulk delete fails for some merchants): We will evaluate the priority of this once we have completed the above Direct Delivery fixes and features.
  • WEB-4592 (Orders marked as “Delivery Partially Failed” on success): This is currently under investigation.
  • WEB-4696 (Deleted listings appearing in search results): We continue to investigate this issue.
  • WEB-2974 (Listing enhancement stuck in “Charging, cannot edit right now” state): We are investigating this issue.
  • WEB-4138 (Confirmation emails failing to deliver): We are currently investigating this issue.

In addition to the above issues, there have been reports of Direct Delivery purchases silently being delivered and the Merchant not getting paid (the order is marked as “Failed”). We have not been able to confirm this report and would like to investigate further, so please file a support ticket with details if you see this.

While progress is welcome, for some merchants the wait is beginning to to tell – and quite understandably so.