Dashboard-of-Dashboards

For those of you with multiple accounts and/or marketplaces, we have deployed today an aggregate dashboard feature.

This shows the all the dashboard coloured tiles for each marketplace on one single page.

You can get to it by clicking on the link ‘Aggregate Dashboard’ to the right of the ‘Welcome To SellerLegend’ title on the main dashboard.

With this deployment, we have now run out of ways of skirting the issue. So our next step with dashboards will have to be the eagerly awaited aggregate dashboard with currency conversion. But that won’t happen until the end of 2Q18 at the earliest.

Right-to-Left Languages and Non-English Translations: Adopt-A-Page.

As you know, SellerLegend already supports multi-language screens. However, I’d understand if you’d be less than impressed if you are a non-English speaker and attempted to use the feature today, as all that is translated is the odd error message and the page navigation items at the top and the bottom of the page.

The reason for the poor state of affairs is because we’d need to translate all the screen contents into their corresponding languages, and that is a very tall order.

So, we thought you might want to help if you need such a translation facility for your own comfort. In a couple of weeks, we will be publishing a set of google sheets with all the screen column headings for each screen and would welcome your assistance to provide us with the translations in your preferred language.

To prevent the translation sheets being spammed, we will only make the sheets available to named volunteers. So, if you’d like to help, please let us know (as a comment below)

  • Your name,
  • Which page(s) you would be interested to translate and
  • Which language(s) you intend to help us with.

We will then send you a link to the specific page where you will be able to provide us with the translated text.

As we are seeing a large influx of sellers from Israel, we have now included support for Right-To-Left languages such as Hebrew. Here’s a view of such a screen. (Translation courtesy of Google Translate, so do not expect it to be accurate!)

Warehouses, Shipments and Suppliers

Starting mid-January, we intend to begin beta testing a significant piece of functionality which will allow Warehouse and Shipments management.

I have alluded to this in earlier teasers: it is essentially the ability to define as many external warehouses as you want, assign products to warehouses, allow for inter-warehouse shipments, status tracking of said shipments, assign suppliers to products, produce suppliers purchase orders define shipping plans, and keep all these moving parts in sync with your inventory forecasting and management portion of SL.

As we need to balance speed of testing against the effort of supporting the testing, we will be limiting the number of participants to 10. Five slots are already reserved for our white label partners so we would need 5 more of you to volunteer to achieve our goal.

The pre-requisite is that

  • You have at least 3 to 5 external warehouses and
  • No more than 50 suppliers

If you exceed that quota, you can still participate, but we’ll just limit your numbers for the beta testing.

We would need participants who have a decent number of shipments per month, as we’d like to complete the testing in no more than a month, if possible.

Interested? Please let us know.

Customer Lists Generation

We have just deployed two often-requested features to generate customer lists.

The two features are visible on your menu only if you have joined SellerLegend Labs (which is free), as these are still in beta and we anticipate you will want many refinements.

You will find the features on the Customers menu, sub-menu Customer Cross-Sell.

The screen is essentially a table showing a join between Customer Details and Order Details.

With the help of the Filters, this table allows you to perform complex searches and generate downloadable customer lists.

For example (but not limited to):

– All buyers who have bought ASIN X or Y
– All repeat buyers
– All buyers who have refunded for ASIN X
– All buyers who have ordered between two dates
– All buyers who have bought more than one product
– All buyers who have not ordered for the past 3 months
– All buyers who redeemed coupon code X
– All buyers within a specified ZIP code
– All buyers in a specific segmentation tier
– All buyers who had a discount between 20% and 50%
– All buyers who refunded on a specific date

And ANY COMBINATION of the above, to create COMPOUND searches, plus much, much more (you just need to play with the filters)

You can then elect to download the list of buyers with their products or download just a buyers list which can be imported directly into Facebook to generate custom audiences.

A Sprinkle of Featurettes

We have deployed today a few minor features (mainly change requests by users):

– The colored tiles in dashboards and Sales Statistics screen can now be toggled to be hidden or displayed. This is to make life easier for those who have laptops with small 13 inch displays and wish to see more data above the fold.

– In Orders screen, refunded orders are now highlighted in light yellow

– Upon change of password, you now have the option to automatically log off from any other devices which may be in a session

– Notifications: when clicking on the View link on any notification item, you are taken to the specific screen and specific item which is notified, rather than being taken to the specific screen but needing to search for the item

– On a failed subscription payment, your next login will take you to the payments screen and invite you to change your credit card details

– In Sales Statistics, the colored tiles now show orders and units as an integer rather than a decimal number

New COGS Feature

Today i was rightly told me off for forgetting to mention a new COGS feature whereby you can now perform inline edits to the to-from dates in a list of COGS time periods

Storage Fees (Again) – Very Long And Boring Post

A few days ago I told you we’d started on the development of storage fees. I also reported that as usual, Amazon won’t make it easy to get to the metrics YOU want (profitability by SKU), as they are only interested in the metrics THEY want (how much to charge you).

Here’s how I explained the challenge back then:

– The storage fee reports come with an ASIN and an FNSKU alongside the storage charges for one month. So, we can certainly provide a breakdown per ASIN, but when it comes to assigning the cost to a product for product profitability calculations, we need to assign it to an SKU rather than an ASIN.

– We can certainly convert the FNSKU to an SKU, that is not a problem. However, in the cases where there is no FNSKU on the report, we are stuck.

– Cases with no FNSKU include comingled inventory and inventory where the UPC or EAN numbers are used instead.

After much head-scratching, here is how we have specified our way out of this mess:

If the Storage Fees report shows a row with an FNSKU present and the FNSKU maps to an SKU, assign the storage fee in the report to its deduced SKU (stemming from FNSKU).

If the Storage Fees report shows a row with FNSKU not present, or FNSKU does not map to an SKU:

– Accumulate estimated-monthly-storage-fee for that report row to an ‘unallocated cost’ bucket
– When all FC/ASINs/FNSKU in the report have been apportioned to their respective SKU, if there is any amount left in the unallocated cost bucket, apportion that amount to the remaining SKUs of the ASIN which have not yet had a fee charged, based on their current inventory on hand

Example

ASIN B0101 has 6 SKUs

– SKU0101
– SKU0102
– SKU0103
– SKU0104
– SKU0105
– SKU0106

Storage Fees Report shows 4 rows for ASIN B0101, two rows which can be directly attributed to an SKU and two rows which cannot

– ASIN B0101 -> FNSKU X0101 ->SKU S0101 cost 5.00 Avg Untis 30
– ASIN B0101 -> FNSKU X0102 ->SKU S0102 cost 3.00 Avg Units 70
– ASIN B0101 -> FNSKU X0101 ->SKU NULL cost 2.00 Avg Units 50
– ASIN B0101 -> FNSKU NULL cost 3.00 Avg Units 80

Processing of the Storage Fees reports rows results in:

a) Calculated total storage fees for ASIN B0101

— $5.00 + $3.00 + $2.00 + $3.00 = $13.00

b) Fees directly attributable to SKUs from the report:

– – SKU 0101 Cost $5.00 (From report)
– – SKU 0102 Cost $3.00 (From report)

c) Fees which are not directly attributable to SKUs from the report (Unused cost bucket) :

— Total $13.00 – ($5.00 + $3.00) = $5.00

d) Unallocated SKUs for ASIN B0101 which have received no cost yet

— SKU0103 current inventory 150
— SKU0104 current inventory 0
— SKU0105 current inventory 60
— SKU0106 current inventory 90

e) Apportionment of Unallocated Bucket Cost to Unallocated SKUs as follows:

— Total units in stock for unallocated SKUs = 150 + 30 + 60 + 90 = 300

— SKU0103 cost = 150 / 300 * $5.00 = $2.50
— SKU0104 cost = 0 / 300 * $5.00 = $0
— SKU0105 cost = 60 / 300 * $5.00 = $1.00
— SKU0106 cost = 90 / 300 * $500 = $1.5

I am sure you cannot wait to spend what is left of your Christmas day to tackle this issue, so I’ll come back and read your comments in an hour or so.

Just kidding. (but we’d be very happy to hear what you think, though)

Amazon API Delays

Over the past 24 hours, we have received 4 support tickets telling us that SellerLegend is trailing behind the SellerCentral dashboard.

We have investigated the 4 instances by comparing the SellerCentral All Orders Report against our dashboard numbers and confirmed they are both in sync. We also have checked our orders pull jobs logs and made sure the reported accounts had been correctly polled for orders every 30 minutes.

It seems that it is an issue with the Amazon API rather than anything being wrong with SellerLegend. If you are experiencing the same issue an need reassurance it is not an SL bug, please send us a copy of your All Orders Report from SellerCentral as well as an Orders download from SellerLegend for the same period an we will be happy to run the numbers for you.

Amazon’s Developer Code of Conduct

Amazon has recently published a brand new ‘Developer’s Code Of Conduct’ which has significant implications both for us as developers but also for you as sellers.

You can read the full code of conduct here:

http://docs.developer.amazonservices.com/…/DG_CodeOfConduct…

It is quite short but telling. Let me extract the 3 clauses which I think are noteworthy:

  • Customers and sellers trust that you will protect information about them. Don’t publicly disclose or share information obtained through MWS (for instance, a seller’s sales revenue or an item’s product description) with any third parties. Do not do this even if you omit or obfuscate the seller’s identity or if you share aggregated seller data without identifying individual sellers.

 

  • Don’t help or allow sellers to violate Amazon’s terms. If you discover that a seller is using your service to violate Amazon terms that apply to the seller, you must immediately notify Amazon and cut off the seller’s MWS access through your service.

 

  • Don’t use robots to programmatically read from (also known as ‘scraping’), or write information to (e.g. creating support contacts), Seller Central or Amazon’s marketplaces

The first clause is important because that puts an end to screenprints and demos using obfuscation. You will notice that ours are literally hand-crafted. No info is obfuscated, but each piece is meticulously replaced by fake data using the browser’s ‘Developers’s Tool’ invoked through the Inspect Element context menu in the browser.

It is further important as it now makes it illegal to provide services like keyword tools, PPC trend analysis, or even product category trends tools or lists (at least, that is how we read it)

The second clause is more significant. If you help a seller to break TOS, you are in Amazon’s cross-hairs. If the developer is in their cross-hairs, where do you think the seller will be?

The third clause is an old chestnut that is easily discounted by both sellers and many of our competitors.

Discuss.