Amazon Cash Flow

 

The amount of money that comes in and out of your business is cash flow. It’s an aspect of running a business that’s frequently misunderstood or disregarded.

To scale an Amazon business and establish a long-term exit strategy, you’ll need sufficient cash flow. Many sellers, unfortunately, struggle to adequately mitigate cash flow issues, leaving their business and exit strategy in jeopardy.

Managing FBA cash flow is critical for Amazon sellers who want to make the most of their business on the e-commerce giant. If you’re an Amazon FBA seller, this article will show you how to manage your Amazon cash flows so you can maximize your Amazon seller profits.

Why Is Cash Flow Important for Amazon Sellers?

Amazon cash flows are critical in determining the health of your Amazon business. They also play an important role in determining how quickly you can expand and protect your business from unforeseen events Amazon experiences.

A cash crunch can prohibit you from taking advantage of lower prices from vendors and suppliers, as well as proactively investing in your firm — both of which are essential for maintaining your market position.

For example, retailers and wholesalers frequently transfer massive amounts of unsold inventory throughout the Fall to accommodate their seasonal offerings. Those who sell on Amazon are in for a huge sourcing opportunity. If you want to take advantage of low-cost inventory purchases, you’ll need cash on hand.

Another benefit of having sufficient Amazon flow and cash on hand is that you can lower the cost of the products you carry. Wholesalers and distributors who supply Amazon sellers might get reduced prices on products or receive additional advantages if they make larger purchases or pay faster.

For instance, by purchasing 200 goods instead of 100, your manufacturer may offer to pay the capital costs associated with this extra purchase. Finding and taking advantage of money-saving opportunities like this one will positively impact your overall cash flow.

Similarly, when you buy in bulk as a private label merchant, you can get a reduced price per item.

How to Manage Your FBA Cash Flow on Amazon

An Amazon cash crunch issue can harm the entire business, resulting in missed sales opportunities, higher inventory expenses due to stock-outs, and poor purchase decisions from traders you have to deal with outside of usual business hours. Follow the tips below to manage your Amazon cash flow effectively.

1. Prepare for slow sales seasons in advance.
   

   Planning for slow sales seasons is one method used by successful Amazon FBA business owners to manage their cash flow. Profitable Amazon FBA business owners prepare for weak sales seasons by stocking up on inventory several months ahead of time. If your products don’t sell as rapidly as expected during busier seasons, you’ll have extra inventory on hand as a safety net.

2. Maintain a cash reserve.
   

   Keeping a cash reserve on the sidelines is another approach Amazon FBA business owners use to manage their cash flow. Three months’ worth of spending should be included in your contingency reserve. The reserve is intended to cover unforeseen bills, sluggish sales seasons, or a disaster.

3. Become familiar with Amazon’s inventory management policies.
   

   Amazon has policies regarding the number of products you can store in your Amazon FBA business account before incurring additional storage fees. Furthermore, Amazon has policies that limit the number of products stored at any given time in its warehouses.These guidelines are in place to prevent stocks from going to waste by sitting on the shelves for too long. Understanding Amazon’s inventory management policy is critical since it affects the number of products you’ll need to acquire to make it through slow periods or unforeseen costs.

4. Examine the sales figures of your competitors.

   Checking your competitors’ Amazon listings is another smart way to manage your cash flow. You can check how many units of stock they’ve sold in a given time frame and at what price. This lets you determine whether prices should be lowered, things should be discounted, or more inventory should be ordered before your competitors sell out.

5. Establish a financial target.

   Setting goals and devising a plan to achieve them is another way successful Amazon FBA business owners manage their cash flow. As an Amazon FBA seller, your ultimate financial goal is to enhance profit while lowering product costs. You can accomplish this by keeping track of all costs associated with each source so you can figure out who provides the best value.

6. Wait for the best products.

   Waiting for the greatest merchandise is a tactic successful Amazon FBA business owners use to manage their cash flow better. They understand that ordering in bulk while prices are at their lowest would optimize their inventory return. They understand that the average cost strategy does not work with Amazon FBA and can increase their profit margin by placing orders at the right moment.

Conclusion

Cash flow is critical for any Amazon business, particularly one that wants to expand, develop, and scale. A cash flow management approach for Amazon FBA business owners will assist you in growing your business without going bankrupt.

While you may have a bad month now and then, with a good cash flow plan in place, you can control your finances — rather than having them manage you. Don’t be afraid to borrow money and start seeking finance when you need it to avoid a cash crunch. PIRS Capital provides Amazon funding to merchants and assists you in running a successful business. To get started, give us a call today and schedule a consultation.

Tackling responsive images

 

One of the main goals when I started with Stitcher was heavily optimized images. Looking at the HTTP Archive stats, it's clear we're doing something wrong. Luckily, the Responsive images spec has been made by a lot of smart people to counter the image problem. My goal was to implement this spec in library in a way that was easy enough for developers to use it to its full extent. We're not completely there yet, but we're close. In this blogpost I want to talk about the challenges I faced creating this library.

To be clear: the goal of the responsive images spec is to reduce bandwith used when downloading images. Images nowadays require so much bandwith. When you think about it, it's insane to load an image which is 2000 pixels wide, when the image on screen is only 500 pixels wide. That's the issue the spec addresses, and that's the issue I wanted to solve in Stitcher.

So I want one image to go in, x-amount of the same image with varying sizes coming out, and let the browser decide which image is the best to load. How could I downscale that source image? That was the most important question I wanted answered. All other problems like accessebility in templates and how to expose the generated image files, were concerns of Stitcher itself.

My first take on downscaling images was the following:

Take the source image and a set of configuration parameters. These parameters would decide the maximum amount of image variations and the minimum width of the image. Eg. I want a maximum of ten images, with the smallest image being 300 pixels wide. Now the algorithm would loop a maximum of 10 times, always creating an image which is 10% smaller in width than the previous one.

You might already see this is not the optimal approach. After all: we're trying to reduce bandwith used when loading images. There is no guarantee an image which is downscaled 10%, is also reduced in size. Much depends on which image codecs are used, and what's in the image itself. But by using this approach early on, I was able to implement this "image factory" with Stitcher. Next I would be working on optimizing the algorithm, but for the time being I could tackle the Stitcher integration.

 Linking with Library

Letting Library know about responsive images was both easy and difficult at the same time. The basic framework was already there. So I could easily create an image provider which used the responsive factory, and returned an array representation of the image. The template syntax looks like this:

<img src="{$image.src}" srcset="{$image.srcset}" sizes="{$image.sizes}" />

Unfortunately, there is no way to automate the sizes part, unless you start crawling all CSS and basically implement a browser engine in PHP. My solution for this part is pre-defined sets of sizes. That's still a work in progress though, I'm not sure yet how to make it easy enough to use. For now, I'm just manually specifying sizes when writing template code.

But the tricky part wasn't the sizes, neither the srcset. It was handling paths and URLs. I've noticed this throughout the whole framework: creating the right paths and URLs (correct amount of slashes, correct root directory etc.) is actually quite the pain to manage. I'm convinced by now I need some kind of helper which always renders the correct paths and URLs. It's on my todo list.

 

A pretty robust library came to be. You could throw it any image, and it would generate a set of variations of that images, scaled down for multiple devices. It returned an object, which Stitcher parsed into a template variable. In templates, the following is now possible.

<img src="{$image.src}" srcset="{$image.srcset}" sizes="{$image.sizes}" />

Like I wrote earlier, the first version of the scaling down algorithm was based on the width of images. It worked, but it wasn't solving the actual problem: optimizing bandwidth usage. The real solution was in downscaling images based on their filesizes. The problem there: how could you know the dimensions of an image, when you know the desired filesize. This is where high school maths came into play. I was actually surprised how much fun I had figuring out this "formula". I haven't been in school for a few years, and I was rather happy I could use some basic maths skills again!

This is what I did:

filesize = 1.000.000
width = 1920
ratio = 9 / 16
height = ratio * width

area = width * height
 <=> area = width * width * ratio

pixelprice = filesize / area
 <=> filesize = pixelprice * area
 <=> filesize = pixelprice * (width * width * ratio)
 <=> width * width * ratio = filesize / pixelprice
 <=> width ^ 2 = (filesize / pixelprice) / ratio
 <=> width = sqrt((filesize / pixelprice) / ratio)

So given a constant pixelprice, I can calculate the required width an image needs to have a specified filesize. Here's the thing though: pixelprice is an approximation of what one pixel in this image costs. That's because not all pixels are worth the same amount of bytes. It heavily depends on which image codecs are used. It is however the best I could do for now, and whilst I might add some more logic in the future, I'd like to try this algorithm out for a while.

So now the Responsive Factory scales down images by filesize instead of width. A much better metric when you're trying to reduce bandwidth usage. This is how the library is used in Stitcher:

use Brendt\Image\Config\DefaultConfigurator;
use Brendt\Image\ResponsiveFactory;

$config = new DefaultConfigurator([
    'driver'      => Config::get('engines.image'),
    'publicPath'  => Config::get('directories.public'),
    'sourcePath'  => Config::get('directories.src'),
    'enableCache' => Config::get('caches.image'),
]);

$responsiveFactory = new ResponsiveFactory($config);

All images in Library go through this factory, the factory will generate x-amount of variations of the image, and the browser decides which one it will download. Its pretty cool, and I hope it will help websites to serve more optimized images, while a developer can still focus on the most important parts of his project.