{"id":1585,"date":"2025-02-01T07:03:24","date_gmt":"2025-02-01T07:03:24","guid":{"rendered":"https:\/\/mailitics.com\/index.php\/2025\/02\/01\/inequality-in-practice-e-commerce-portfolio-analysis-adc3d0876acd\/"},"modified":"2025-02-01T07:03:24","modified_gmt":"2025-02-01T07:03:24","slug":"inequality-in-practice-e-commerce-portfolio-analysis-adc3d0876acd","status":"publish","type":"post","link":"https:\/\/mailitics.com\/index.php\/2025\/02\/01\/inequality-in-practice-e-commerce-portfolio-analysis-adc3d0876acd\/","title":{"rendered":"Inequality in Practice: E-commerce Portfolio Analysis"},"content":{"rendered":"
Inequality in Practice: E-commerce Portfolio Analysis \n \t
\n <\/BR> \n \n \t
\n <\/BR><\/p>\n
\n
From Mathematical Theory to Actionable Insights: A 6-Year Shopify Case\u00a0Study<\/h4>\nImage generated by DALL-E, based on author\u2019s prompt, inspired by \u201cThe Bremen Town Musicians\u201d<\/figcaption><\/figure>\n
Are your top-selling products making or breaking your business?<\/p>\n
It\u2019s terrifying to think your entire revenue might collapse if one or two products fall out of favor. Yet spreading too thin across hundreds of products often leads to mediocre results and brutal price\u00a0wars.<\/p>\n
Discover how a 6-year Shopify case study uncovered the perfect balance between focus and diversification.<\/p>\n
Why bother?<\/h4>\n
Understanding concentration in your product portfolio is more than simply an intellectual exercise; it has a direct impact on crucial business choices. From inventory planning to marketing spend, understanding how your revenue is distributed among goods impacts your approach.<\/p>\n
This post walks through practical strategies for monitoring concentration, explaining what these measurements actually mean and how to get useful insights from your\u00a0data.<\/p>\n
I\u2019ll take you through fundamental metrics and advanced analysis, including interactive visualisations that bring the data to\u00a0life.<\/p>\n
I am also sharing chunks of R code used in this analysis. Use it directly or adapt the logic to your preferred programming language.<\/p>\n
The Concentration Question<\/h3>\n
Looking at market analysis or investment theory, we often focus on concentration\u200a\u2014\u200ahow value is distributed across different elements. In e-commerce, this translates into a fundamental question: How much of your revenue should come from your top products?<\/p>\n
Is it better to have several strong sellers or a broad product range? This isn\u2019t just a theoretical question\u00a0\u2026<\/p>\n
Having most of your revenue tied to few products means your operations are streamlined and focused. But what happens when market preferences shift? Conversely, spreading revenue across hundreds of products might seem safer, but it often means you lack any real competitive advantage.<\/p>\n
So where\u2019s the optimal point? Or rather what is the optimal range, and how various ratios describe\u00a0it.<\/p>\n
What makes this analysis particularly valuable is that it is based on real data from a business that kept expanding its product range over\u00a0time.<\/p>\n
Getting the Data\u00a0Right<\/h3>\n
On Datasets<\/h4>\n
This analysis was done for a real US-based e-commerce store\u200a\u2014\u200aone of our clients who kindly agreed to share their data for this article. The data spans six years of their growth, giving us a rich view of how product concentration evolves as business\u00a0matures.<\/p>\n
While working with actual business data gives us genuine insights, I\u2019ve also created a synthetic dataset in one of the later sections. This small, artificial dataset helps illustrate the relationships between various ratios in a more controlled setting\u200a\u2014\u200ashowing patterns \u201ccounting on fingers\u201d.<\/p>\n
To be clear: this synthetic data was created entirely from scratch and only loosely mimics general patterns seen in real e-commerce\u200a\u2014\u200ait has no direct connection to our client\u2019s actual data. This is different from my previous article, where I generated synthetic data based on real patterns using Snowflake functionality.<\/p>\n
Data Export<\/h4>\n
The main analysis draws from real data, but that small artificial dataset serves an important purpose\u200a\u2014\u200ait helps explain relationships between various ratios in a way that\u2019s easy to grasp. And trust me, having such a micro dataset with clear visuals comes in really handy when explaining complex dependencies to stakeholders\u00a0\ud83d\ude09<\/p>\n
The raw transaction export from Shopify contains everything we require, but we must arrange it properly for concentration analysis. The data contains all of the products for each transaction, but the date is only in one row per transaction, thus we must propagate it to all products while retaining the transaction id. Probably not for the first iteration of the study, but if we want to fine-tune it, we should consider how to handle discounts, returns, and so on. In the case of foreign sales, conduct a global and country-specific study.<\/p>\n
We have a product name and an SKU, both of which should adhere to some naming convention and logic when dealing with variants. If we have a master catalogue with all of these descriptions and codes, we are very fortunate. If you have it, use it, but compare it to the \u2018ground truth\u2019 with actual transaction data.<\/p>\n
Product Variants<\/h4>\n
In my case, the product names were structured with a base name and a variant separated by a dash. Very simple to use, divided into main product and variants. Exceptions? Of course, they are always present, especially when dealing with 6 years of highly successful ecommerce data:). For instance, some names (e.g. \u201cAll-purpose\u201d) included a dash, while others did not. Then, some did have variants, while some did not. So expect for some tweaks here, but this is a critical\u00a0stage.<\/p>\nNumber of unique products, with and without variants\u200a\u2014\u200aall charts rendered by author, with own R\u00a0code<\/figcaption><\/figure>\n
If you\u2019re wondering why we need to exclude variations from concentration analysis, the figure above illustrates it clearly. The values are considerably different, and we would expect radically different results if we analysed concentration with variants.<\/p>\n
The analysis is based on transactions, counting number of products with\/without variants in a given month. But if we have a large number of variants, not all of them will be present in one-month transactions. Yes, that is correct\u200a\u2014\u200aso let us consider a larger time range, one\u00a0year.<\/p>\nProducts, their variants, by transaction date,\u00a0yearly<\/figcaption><\/figure>\n
I calculated the number of variants per base product in a calendar year based on what we have in transactions. The number of variants per base product is divided into several bins. Let\u2019s take the year 2024. The plot shows that we have somewhat around 170 base items, with less than half having only one variant (light green bar). However, the other part had more than one version, and what is noteworthy (and, I believe, non-obvious, unless you work in apparel ecommerce) is that we have products with a really large number of versions. The black bin contains items that come in 100 or more different variants.<\/p>\n
If you guessed that they were increasing their offerings by introducing new products while keeping old ones available, you are correct. But wouldn\u2019t it be interesting to know whether the differences stem from heritage or new products? What if we just included products introduced in the current year? We may check it by using the date of product introduction rather than transactions. Because our only dataset is a transaction dump, the first transaction for each product is taken as the introduction date. And for each product, we take all versions that appeared in transactions, with no time constraints (from product introduction to the most current\u00a0record).<\/p>\nProducts, their variants, by product introduction date,\u00a0yearly<\/figcaption><\/figure>\n
Now let\u2019s have these two plots side by side for easy comparison. Taking transactions dates we have more products in each year, and the difference grows\u200a\u2014\u200asince there are also transactions with products introduced previously. No suprises here, as expected. If you were wondering why data for 2019 differ\u200a\u2014\u200anice catch. In fact, shop started operation in 2018, but I removed these few initial months; still, it is their impact what makes the difference in\u00a02019.<\/p>\n
Products variants and it\u2019s impact on revenue is not our focus in this article. But as it is often in real analysis, there are \u2018branching\u2019 options, as we progress, even in the initial phase. We haven\u2019t even finished data preparation, and it is already getting interesting.<\/p>\nProducts, their variants, by product introduction and transaction, yearly<\/figcaption><\/figure>\nSame data as above, facet by\u00a0bin<\/figcaption><\/figure>\n
Understanding the product structure is critical for conducting meaningful concentration analyses. Now that our data is appropriately formatted, we can examine actual concentration measurements and what they reveal about ideal portfolio structure. In the following part, we\u2019ll look at these measurements and what they mean for e-commerce businesses.<\/p>\n
When it comes to determining concentration, economists and market analysts have done the heavy lifting for us. Over decades of research into markets, competitiveness, and inequality, they\u2019ve produced powerful analytical methods that have proven useful in a variety of sectors. Rather than developing novel metrics for e-commerce portfolio analysis, we can use existing time-tested methods.<\/p>\n
Let\u2019s see how theoretical frameworks can shed light on practical e-commerce questions.<\/p>\n
Herfindahl-Hirschman Index<\/h4>\n
HHI (Herfindahl-Hirschman Index) is probably the most common way to measure concentration. Regulators use it to check if a market isn\u2019t becoming too concentrated\u200a\u2014\u200athey take percentages of each company\u2019s market share, square them, and add up. Simple as that. The result can be anywhere from nearly 0 (many small players) to 10,000 (one company takes it\u00a0all).<\/p>\n
Why use HHI for e-commerce portfolio analysis? The logic is straightforward\u200a\u2014\u200ainstead of companies competing in a market, we have products competing for revenue. The math works exactly the same way\u200a\u2014\u200awe take each product\u2019s share of total revenue, square it, and sum up. High HHI means revenue depends on few products, while low HHI shows revenue is spread across many products. This gives us a single number to track portfolio concentration over\u00a0time.<\/p>\n<\/figure>\nHHI, and Products for\u00a0context<\/figcaption><\/figure>\n
Pareto<\/h4>\n
Who has not heard of Pareto\u2019s rules? In 1896, Italian economist Vilfredo Pareto observed that 20% of the population held 80% of Italy\u2019s land. Since then, this pattern has been found in a variety of fields, including wealth distribution and retail\u00a0sales.<\/p>\n
While popularly referred to as the \u201c80\/20 rule,\u201d the Pareto principle is not limited to these figures. We can use any x-axis criterion (for example, the top 30% of products) to determine the appropriate y value (revenue contribution). The Lorenz curve, formed by linking these locations, provides a complete picture of concentration.<\/p>\nPareto lines for different revenue share thresholds<\/figcaption><\/figure>\n
The chart above shows how many products do we need to achieve certain revenue share (of the monthly revenue). I took arbitrarily cuts at\u00a0.2,\u00a0.3,\u00a0.5,\u00a0.8,\u00a0.95, and of course also including 1\u200a\u2014\u200awhich means total number of products, contributing to 100% of revenue in a given\u00a0month.<\/p>\n
Lorenz curve<\/h4>\n
If we sort products by their revenue contribition, and chart the line, we get Lorenz curve. On both axis we have percentages, of products and their reveue share. I case of perfectly uniform revenue distribution, we\u2019d have a straight line, while in case of \u201cperfect concentration\u201d, very steep curve, climbing close to 100% revenue, and then rapidly turning right, to include some residual revenue from other products.<\/p>\nLorenz curve<\/figcaption><\/figure>\n
It is interesting to see that line, but in most cases it will look quite similar, like a \u201cbended stick\u201d. So let us now compare these lines for few previous months, and also few years back (sticking to October). The monthly lines are quite similar, and if you think\u200a\u2014\u200ait would be good to have some interactivity in this plot, you are absolutely right. The yearly comparison shows more differences (we still have monthly data, taking October in each year), and this is understandable, since these measurements are more distant in\u00a0time.<\/p>\nLorenz curve\u200a\u2014\u200acomparing periods<\/figcaption><\/figure>\n
So we do see differences between the lines, but can\u2019t we quantify them somehow, not to rely entirely on visual similarity? Definitely, and there is a ratio for that\u200a\u2014\u200aGini Ratio. And by the way, we will have quite a lot of ratios in next chapters.<\/p>\n
Gini Ratio<\/h4>\n
To translate shape of Lorenz curve into numeric value, we can use Gini ratio\u200a\u2014\u200adefined as a ratio between two areas, above and below the equality line. On a plot below it is a ratio between dark and light blue\u00a0areas.<\/p>\nGini ratio visualization<\/figcaption><\/figure>\n
Let us then visualize for two periods\u200a\u2014\u200aOctober 2019, and October 2024, exact same periods, as we have on one of the plots\u00a0before.<\/p>\nGini ratio, comparing two\u00a0periods<\/figcaption><\/figure>\n
Once we have good understanding, with visuals, how the Gini ratio is calculated, let\u2019s plot it, over the whole\u00a0period.<\/p>\n
I use R for analysis, so I have Gini ratio easily available (as well as other ratios, which I will show later). The initial data table (x3a_dt) contains revenue per product, per month. The resulting one has Gini ratio per\u00a0month.<\/p>\n
Good we have all these packages for heavy lifting. The math behind is not super complicated, but our time is precious.<\/p>\n<\/figure>\n
The plot below shows the result of calculations.<\/p>\nGini over\u00a0time<\/figcaption><\/figure>\n
I haven\u2019t included a smoothing line, with its confidence interval channel, since we do not have measurement points, but the result of Gini calculation, with its own errors distribution. To be very strict and precise on math, we\u2019d need to calculate the confidence interval, and based on that plot smoothed line. The results are\u00a0below.<\/p>\nGini over time, with trend\u00a0line<\/figcaption><\/figure>\n
Since we do not use directly statistical significance of calculated ratio, this super strict approach is a little bit an overkill. I haven\u2019t done it while charting trend line for HHI, nor will do in next plots. But it is good to be aware of this\u00a0nuance.<\/p>\n
We have seen so far two ratios\u200a\u2014\u200aHHI and Gini, and they are far from being identical. Lorenz curve closer to diagonal indicates more uniform distribution, which is what we have for October 2019, but the HHI is higher, than for 2024, indicating more concentration in 2019. Maybe I made a mistake in calculations, even worse, early on during data preparation? That would be really unfortunate. Or the data is ok, but we are struggling with proper interpretation?<\/p>\n
I have quite often moments of such doubts, especially when moving with the analysis really quick. So how do we cope with that, tightening grip on data and our understanding of dependencies? Bear in mind, that whatever analysis you do, there is always first time. And quite often we do not have a luxury of \u2018leisure\u2019 research, it is more often already work for a Client (or a superior, stakeholder, whoever requested it, even ourselves, if it is our initiative).<\/p>\n
Tightening grip<\/h3>\n
We need to have a good understanding of how to interpret all these ratios, including dependencies between them. If you plan to present your results to others, questions here are guaranteed, so better to be well prepared. We can work with an existing dataset, or we can generate a small set, where it will be easier to catch dependencies. Let us follow the latter approach.<\/p>\n
Let us start with creating a small\u00a0dataset,<\/p>\n
library(data.table)
#-- Create sample revenue data revenue <- list( \"2021\" = rep(15, 10), # 10 values of 15 \"2022\" = c(rep(100, 5), rep(10, 25)), # 5 values of 100, 25 values of 10 \"2023\" = rep(25, 50), # 50 values of 25 \"2024\" = c(rep(100, 30), rep(10, 70)) # 30 values of 100, 70 values of 10 )<\/pre>\n
combining it into a data.table.<\/p>\n
#-- Convert to data.table in one step x_dt <- data.table( year = rep(names(revenue), sapply(revenue, length)), revenue = unlist(revenue) )<\/pre>\n
A quick overview of the\u00a0data.<\/p>\nExample dataset<\/figcaption><\/figure>\n
It seems we have what we needed\u200a\u2014\u200aa simple dataset, but still quite realistic. Now we are proceeding with calculations and charts, similar to what we had for a real dataset\u00a0before.<\/p>\n
And rendering plots.<\/p>\nRatios comparison<\/figcaption><\/figure>\n
These charts help a lot in understanding ratios, relations between them and to data. It is always a good idea to have such micro analysis, for ourselves and for stakeholders\u200a\u2014\u200aas \u2018back pocket\u2019 slides, or even sharing them\u00a0upfront.<\/p>\n
Nerdy detail\u200a\u2014\u200ahow to slightly shift the line, so it doesn\u2019t overlap, and add labels within a plot? Render a plot, and then make manual fine tuning, expecting several iterations.<\/p>\n
#-- shift the line xl_dt[year == \"2021\", `:=` (cum_rev_pct = cum_rev_pct - .01)]<\/pre>\n
For labelling I use ggrepel, but as a default, it will label all the points, while we need only one per line. An in addition deciding which one, for good looking\u00a0chart.<\/p>\n
#-- decide which points to label labs_key2_dt <- data.table( year = c(\"2021\", \"2022\", \"2023\", \"2024\"), position = c(4, 5, 25, 30))
#-- set keys list(xl_dt, labs_key2_dt) |> lapply(setkey, year)
#-- join label_positions2 <- xl_dt[ labs_key2_dt, on = .(year), # join on 'year' .SD[get('position')], # Use get('position') to reference the position from labs_key_dt by = .EACHI] # for each year<\/pre>\n
Render the\u00a0plot.<\/p>\n
#-- render plot plot_22b <- xl_dt |> ggplot(aes(cum_prod_pct, cum_rev_pct, color = year, group = year, label = year)) + geom_line(linewidth = .2) + geom_point(alpha = .8, shape = 21) + theme_bw() + scale_color_viridis_d(option = \"H\", begin = 0, end = 1) + ggrepel::geom_label_repel( data = label_positions2, force = 10, box.padding = 2.5, point.padding = .3, seed = 3, direction = \"x\") + ... additional styling <\/pre>\n
More Ratios<\/h3>\n
I began with HHI, the Lorenz curve, and the accompanying Gini ratios, as they appeared to be good starting points for concentration and inequality measurements. However, there are numerous different ratios used to define distributions, whether for inequality or in general. It\u2019s unlikely that we\u2019d employ all of them at once, therefore select the subset that provides the most insights for your specific challenge.<\/p>\n
With a proper structure of a dataset, it is quite straightforward to calculate them. I am sharing code snippets, with several ratios calculated monthly. We use a dataset, we already have\u200a\u2014\u200amonthly revenue per product (base products, excluding variants).<\/p>\n<\/figure>\n
Starting with ratios from the ineq\u00a0package.<\/p>\n
#---- inequality ---- x3_ineq_dt <- x3a_dt[, .( # Classical inequality\/concentration measures gini = ineq::ineq(revenue, type = \"Gini\"), # Gini coefficient hhi = ineq::Herfindahl(revenue), # Herfindahl-Hirschman Index hhi_f = sum((rev_pct*100)^2), # HHI - formula atkinson = ineq::ineq(revenue, type = \"Atkinson\"), # Atkinson index theil = ineq::ineq(revenue, type = \"Theil\"), # Theil entropy index kolm = ineq::ineq(revenue, type = \"Kolm\"), # Kolm index rs = ineq::ineq(revenue, type = \"RS\"), # Ricci-Schutz index entropy = ineq::entropy(revenue), # Entropy measure hoover = mean(abs(revenue - mean(revenue)))\/(2 * mean(revenue)), # Hoover (Robin Hood) index<\/pre>\n
Diustribution shape and top\/bottom shares and\u00a0ratios.<\/p>\n
# Count measures above_mean_n = sum(revenue > mean(revenue)), # Number of products above mean above_2mean_n = sum(revenue > 2*mean(revenue)), # Number of products above 2x mean top_quartile_n = sum(revenue > quantile(revenue, 0.75)), # Number of products in top quartile zero_revenue_n = sum(revenue == 0), # Number of products with zero revenue within_1sd_n = sum(abs(revenue - mean(revenue)) <= sd(revenue)), # Products within 1 SD within_2sd_n = sum(abs(revenue - mean(revenue)) <= 2*sd(revenue)), # Products within 2 SD<\/pre>\n
Revenue above (or below) the threshold.<\/p>\n
# Revenue above threshold rev_above_mean = sum(revenue[revenue > mean(revenue)]) # Revenue from products above mean ), month]<\/pre>\n
The resulting table has 40 columns, and 72 rows (months).<\/p>\n<\/figure>\n
As mentioned earlier, it is difficult to imagine, one would work with 40 ratios, so I am rather showing a method how to calculate them, and one should pick relevant ones. As always, it is good to visualize and see how they relate to each\u00a0other.<\/p>\nSelected ratios over\u00a0time<\/figcaption><\/figure>\n
We can calculate correlation matrix between all ratios, or selected\u00a0subset.<\/p>\n
# Select key metrics for a clearer visualization key_metrics <- c(\"gini\", \"hhi\", \"atkinson\", \"theil\", \"entropy\", \"hoover\", \"top1_share\", \"top3_share\", \"top5_share\", \"unique_products\")
And then we can plot some interesting pairs. Of course, some of them have positive or negative correlation by definition<\/em>, while in other cases it is not that\u00a0obvious.<\/p>\nSelected ratios, with negative correlation<\/figcaption><\/figure>\n
Show me the\u00a0money<\/h3>\n
We started analysis with ratios and Lorenz curve as a top-down overview. It is a good start, but there are two complications\u200a\u2014\u200athe ratios have a relatively broad range, when the business is doing ok, and there is hardly connection to actionable insights. Even if we notice that the ratio is on the edge, or outside of the safe range, it is unclear what we should do. And instructions like \u201cdecrease concentration\u201d are a little ambiguous.<\/p>\n
E-commerce talks and breaths products, so to make analysis relatable, we need to reference to particular products. People would also like to understand which products constitute core 50%, 80% of revenue, and equally important, if these products stay consistently as top contributors.<\/p>\n
Let us take one month, August 2024 and see which products contributed to 50% revenue in that month. Then, we check revenue from these exact products in other months. There are 5 products, generating (at least) 50% revenue in\u00a0August.<\/p>\nProducts revenue, facets by\u00a0product<\/figcaption><\/figure>\n
We can also render more visually appealing plot with a streamgraph. Both plots show exact same dataset, but they complement each other nicely\u200a\u2014\u200abar plots for precision, while streamgraph for a\u00a0story.<\/p>\nProducts revenue, stream\u00a0graph<\/figcaption><\/figure>\n
The red line indicated selected month. If you feel \u201citching\u201d to shift that line, like in an old-fashioned radio, you are absolutely right\u200a\u2014\u200athat should be an interactive chart, and actually it is, along with a slider for revenue share percentage (we produced it for a\u00a0Client).<\/p>\n
So what if we shift that red \u2018tuning line\u2019 a little bit backwards, maybe to 2020? The logic in data preparation is very similar\u200a\u2014\u200aget products contributing to a certain revenue share threshold, and check the revenue from these products in other\u00a0months.<\/p>\nProducts revenue, stream\u00a0graph<\/figcaption><\/figure>\n
With interactivity on two elements\u200a\u2014\u200arevenue contribution percentage and the date, one can learn a lot about the business, and this is exactly the point of these charts. One can look from different angles:<\/p>\n
\n
concentration, how many products do we need for certain revenue threshold,<\/li>\n
products themselves, do they stay in certain revenue contribution bin, or do they change and why? Is it seasonality, a valid replacement, lost supplier or something else?<\/li>\n
time window, whether we look at one month or a whole\u00a0year,<\/li>\n
seasonality, comparing similar time of a year with previous\u00a0periods.<\/li>\n<\/ul>\n
Summary<\/h3>\n
What the Data Tells\u00a0Us<\/h4>\n
Our 6-year dataset reveals the evolution of an e-commerce business from high concentration to balanced growth. Here are the key patterns and\u00a0lessons:<\/p>\n
With 6 years of data, I had a unique chance to watch concentration metrics evolve as the business grew. Starting with just a handful of products, I saw exactly what you\u2019d expect\u200a\u2014\u200asky-high concentration. But as new products entered the mix, things got more interesting. The business found its rhythm with a dozen or so top performers, and the HHI settled into a comfortable 700\u2013800\u00a0range.<\/p>\n
Here\u2019s something fascinating I discovered: concentration and inequality might sound like twins, but they\u2019re more like distant cousins. I noticed this while comparing HHI against Lorenz curves and their Gini ratios. Trust me, you\u2019ll want to get comfortable with the math before explaining these patterns to stakeholders\u200a\u2014\u200athey\u2019ll smell uncertainty from a mile\u00a0away.<\/p>\n
Want to really understand these metrics? Do what I did: create a dummy dataset so simple it\u2019s almost embarrassing. I\u2019m talking basic patterns that a fifth-grader could grasp. Sounds like overkill? Maybe, but it saved me countless hours of head-scratching and misinterpretation. Keep these examples in your back pocket\u200a\u2014\u200aor better yet, share them upfront. Nothing builds confidence like showing you\u2019ve done your homework.<\/p>\n
Look, calculating these ratios isn\u2019t rocket science. The real magic happens when you dig into how each product contributes to your revenue. That\u2019s why I added the \u201cshow me the money\u201d section\u200a\u2014\u200aI don\u2019t believe in quick fixes or magic formulas. It\u2019s about rolling up your sleeves and understanding how each product really\u00a0behaves.<\/p>\n
As you\u2019ve probably noticed yourself, these streamgraphs I showed you are practically begging for interactivity. And boy, does that add value! Once you\u2019ve got your keys and joins sorted out, it\u2019s not even that complicated. Give your users an interactive tool, and suddenly you\u2019re not drowning in one-off questions anymore\u200a\u2014\u200athey\u2019re finding insights themselves.<\/p>\n
Here\u2019s a pro tip: use this concentration analysis as your foot in the door with stakeholders. Show your product teams that streamgraph, and I guarantee their eyes will light up. When they start asking for interactive versions, you\u2019ve got them hooked. The best part? They\u2019ll think it was their idea all along. That\u2019s how you get real adoption\u200a\u2014\u200aby letting them discover the value themselves.<\/p>\n
Data Engineering Takeaways<\/h4>\n
While quite often we generally know what to expect in a dataset, it is almost guaranteed that there will be some nuances, exceptions, or maybe even surprises. It\u2019s good to spend some time reviewing datasets, using dedicated functions (like str, glimpse in R), looking for empty fields, outliers, but also simply scrolling through to understand the data. I like comparisons, and in this case, I\u2019d compare to smelling fish on a market before jumping to prepare sushi\u00a0\ud83d\ude42<\/p>\n
Then, if we work with a raw data export, quite likely there will be several columns in the data dump; after all, if we click \u2018export all\u2019, wouldn\u2019t we expect exactly that? For most analysis we will need a subset of these columns, so it\u2019s good to trim and keep only what we need. I assume we work with a script, so if it turns out, we need more, not an issue, just add missed column and rerun that\u00a0chunk.<\/p>\n
In the dataset dump there was a timestamp in one row per transaction, while we needed it per each product. Hence some light data wrangling to propagate these timestamps to all the products.<\/p>\n
After cleaning the dataset, it\u2019s important to consider the context of analysis, including the questions to be answered and the necessary changes to the data. This \u201ccontextual cleaning\/wrangling\u201d is critical since it determines whether the analysis succeeds or fails. In our situation, the goal was to analyse product concentration, therefore filtering out variants (size, colour, etc.) was essential. If we had skipped that, the outcome would have been radically different.<\/p>\n
Quite often we can expect some \u201ctraps\u201d, where initially it seems we can apply simple approach, while actually, we should add a bit of sophistication. As an example\u200a\u2014\u200aLorenz curve, where we need to calculate how many products do we need to get to a certain revenue threshold. This is where I use rolling joins, which fit here perfectly.<\/p>\n
The core logic to produce streamgraphs is to find products which constitute certain revenue percentage in a given month, then \u201cfreeze\u201d them and get their revenue in other months. The toolset I used was adding extra column, with a product number, after sorting per month, and then playing with keys and\u00a0joins.<\/p>\n
An important element of this analysis was adding interactivity, allowing users to play with some parameters. That raises the bar, as we need all these operations to be performed lightning fast. The ingredients we need are right data structure, additional columns, proper keys and joins. Prepare as much as possible, precalculating in a data warehouse, so the dashboarding tool is not overloaded. Take caching into\u00a0account.<\/p>\n
How to\u00a0Start?<\/h4>\n
Strike a balance between delivering what stakeholders request and exploring potentially valuable insights they haven\u2019t asked for yet. The analysis I presented follows this pattern\u200a\u2014\u200agetting initial concentration ratios is straightforward, while building an interactive streamgraph optimized for lightning-fast operation requires significant effort.<\/p>\n
Start small and engage others. Share basic findings, discuss what you could learn together, and only then proceed with more labor-intensive analysis once you\u2019ve secured genuine interest. And always maintain a solid grip on your raw data\u200a\u2014\u200ait\u2019s invaluable for answering those inevitable ad-hoc questions quickly.<\/p>\n
Building a prototype before full production allows for validation of interest and feedback without devoting too much time. In my case, such simple concentration ratios sparked debates that eventually led to the more advanced interactive studies on which stakeholders rely\u00a0today.<\/p>\nStart small, secure genuine interest\u00a0\u2026\u00a0:-)) \/ image generated by DALL-E, based on author\u2019s\u00a0prompt.<\/figcaption><\/figure>\n
I\u2019ll show you how I prepared the data at each step of this analysis. Since I used R, I\u2019ll include the actual code snippets\u200a\u2014\u200athey\u2019ll help you get started faster, even if you\u2019re working in a different language. This is the code I used for the study, though you\u2019ll probably need to adapt it to your specific needs rather than just copying it over. I decided to keep the code separate from the main analysis, to make it more streamlined and readable for both technical and business\u00a0users.<\/p>\n
While I am presenting analysis based on Shopify export, there is no limitation for a particular platform, we just need transactions data.<\/p>\n
Shopify export<\/h4>\n
Let\u2019s start with getting our data from Shopify. The raw export needs some work before we can dive into concentration analysis\u200a\u2014\u200ahere\u2019s what I had to deal with\u00a0first.<\/p>\n
We start with export of raw transactions data from Shopify. It might take some time, and when ready, we get an email with links to download.<\/p>\n
#-- 0. libs pacman::p_load(data.table)
#-- 1.1 load data; the csv files are what we get as a full export from Shopify xs1_dt <- fread(file = \"shopify_raw\/orders_export_1.csv\") xs2_dt <- fread(file = \"shopify_raw\/orders_export_2.csv\") xs3_dt <- fread(file = \"shopify_raw\/orders_export_3.csv\")<\/pre>\n
Once we have data, we need to combine these files into one dataset, trim columns and perform some cleansing.<\/p>\n
#-- 1.2 check all columns, limit them to essential (for this analysis) and bind into one data.table xs1_dt |> colnames() # there are 79 columns in full export, # so we select a subset, relevant for this analysis sel_cols <- c(\"Name\", \"Email\", \"Paid at\", \"Fulfillment Status\", \"Accepts Marketing\", \"Currency\", \"Subtotal\", \"Lineitem quantity\", \"Lineitem name\", \"Lineitem price\", \"Lineitem sku\", \"Discount Amount\", \"Billing Province\", \"Billing Country\")
#-- combine into one data.table, with a subset of columns xs_dt <- data.table::rbindlist(l = list(xs1_dt, xs2_dt, xs3_dt), use.names = T, fill = T, idcol = T) %>% .[, ..sel_cols]<\/pre>\n
Some data preparations.<\/p>\n
#-- 2. data prep #-- 2.1 replace spaces in column names, for easier handling sel_cols_new <- sel_cols |> stringr::str_replace(pattern = \" \", replacement = \"_\") setnames(xs_dt, old = sel_cols, new = sel_cols_new)
Now we focus on transactions dataset. In the export files, the transaction amount and timestamp is in only one row per all items in the basket. We need to get these timestamps and propagate to all\u00a0items.<\/p>\n
#-- 3 transactions dataset #-- 3.1 subset transactions #-- limit columns to essential for transaction only trans_sel_cols <- c(\"Transaction_id\", \"Email_hash\", \"Paid_at\", \"Subtotal\", \"Currency\", \"Billing_Province\", \"Billing_Country\")
#-- get transactions table based on requirement of non-null payment - as payment (date, amount) is not for all products, it is only once per basket xst_dt <- xs_dt[!is.na(Paid_at) & !is.na(Transaction_id), ..trans_sel_cols]<\/pre>\n
#-- date columns xst_dt[, `:=` (date = as.Date(`Paid_at`))] xst_dt[, `:=` (month = lubridate::floor_date(date, unit = \"months\"))]<\/pre>\n
Some extra information, as I call them, derivatives<\/em>.<\/p>\n
#-- 3.2 is user returning? their n-th transaction setkey(xst_dt, Paid_at) xst_dt[, `:=` (tr_n = 1)][, `:=` (tr_n = cumsum(tr_n)), Email_hash]
Time for data cleaning. First up: splitting the Lineitem_name into base products and their variants. In theory, these are separated by a dash (\u201c-\u201d). Simple, right? Not quite\u200a\u2014\u200asome product names, like \u2018All-Purpose\u2019, contain dashes as part of their name. So we need to handle these special cases first, temporarily replacing problematic dashes, doing the split, and then restoring the original product\u00a0names.<\/p>\n
#-- 6. cleaning, aggregation on product names #-- 6.1 split product name into base and variants #-- split product names into core and variants product_cols <- c(\"base_product\", \"variants\") #-- with special treatment for 'all-purpose' x3_dt[stringr::str_detect(string = Lineitem_name, pattern = \"All-Purpose\"), (product_cols) := { tmp = stringr::str_replace(Lineitem_name, \"All-Purpose\", \"AllPurpose\") s = stringr::str_split_fixed(tmp, pattern = \"[-\/]\", n = 2) s = stringr::str_replace(s, \"AllPurpose\", \"All-Purpose\") .(s[1], s[2]) }, .I]<\/pre>\n
It is good to make validation after each\u00a0step.<\/p>\n
We keep moving with data cleaning\u200a\u2014\u200athe exact steps depend of course on a particular dataset, but I share my flow, as an\u00a0example.<\/p>\n
#-- two scenarios, to cope with `(32-ounce)` in prod name; we don't want that hyphen to cut the name x3_dt[stringr::str_detect(string = `Lineitem_name`, pattern = \"ounce\", negate = T) & stringr::str_detect(string = `Lineitem_name`, pattern = \"All-Purpose\", negate = T), (product_cols) := { s = stringr::str_split_fixed(string = `Lineitem_name`, pattern = \"[-\/]\", n = 2); .(s[1], s[2]) }, .I]
We use eval(sel_cols[6]) to get the name of a column sel_cols[6] which is Currency.<\/p>\n
We also need to deal with NA\u2019s, but with an understanding of a dataset\u200a\u2014\u200awhere we could have NA\u2019s and where they are not supposed to be, indicating an issue. In some columns, like `Discount_Amount`, we have values (actual discount), zeros, but also sometimes NA\u2019s. Checking final price, we conclude they are\u00a0zeros.<\/p>\n
#-- deal with NA'a - replace them with 0 sel_na_cols <- c(\"Discount_Amount\") x3_dt[, (sel_na_cols) := lapply(.SD, fcoalesce, 0), .SDcols = sel_na_cols]<\/pre>\n
For consistency and convenience, changing all column names to lowercase.<\/p>\n
setnames(x3_dt, tolower(names(x3_dt)))<\/pre>\n
And verification.<\/p>\n<\/figure>\n
Of course review dataset, with some test aggregations, and also just printing it\u00a0out.<\/p>\n
Save dataset as both Rds (native R format) and\u00a0csv.<\/p>\n
Conducting steps above we should have a clean dataset, for futher analysis. The code should serve as a guideline, but also can be used directly, if you work in\u00a0R.<\/p>\n
Versions<\/h4>\n
As a first glimpse, we will check number of products per month, both base_product, and including all versions.<\/p>\n
As a small cleaning, I take only complete\u00a0months.<\/p>\n
#-- names, as we want them on plot setnames(x3_c_dt, old = c(\"base_products\", \"products\"), new = c(\"base\", \"all, with variants\"))
#-- long form x3_d_dt <- x3_c_dt[, melt.data.table(.SD, id.vars = \"month\", variable.name = \"Products\")]
#-- reverse factors, so they appear on plot in a proper order x3_d_dt[, `:=` (Products = forcats::fct_rev(Products))]<\/pre>\n<\/figure>\n
We are ready to plot the\u00a0dataset.<\/p>\n
plot_01_w <- x3_d_dt |> ggplot(aes(month, value, color = Products, fill = Products)) + geom_line(show.legend = FALSE) + geom_area(alpha = .8, position = position_dodge()) + theme_bw() + scale_fill_viridis_d(direction = -1, option = \"G\", begin = 0.3, end = .7) + scale_color_viridis_d(direction = -1, option = \"G\", begin = 0.3, end = .7) + labs(x = \"\", y = \"Products\", title = \"Unique products, monthly\", subtitle = \"Impact of aggregation\") + theme(... additional styling)<\/pre>\n
The next plot shows the number of variants grouped into bins. This gives us a chance to talk about chaining operations in R, particularly with the data.table package. In data.table, we can chain operations by opening a new bracket right after closing one\u200a\u2014\u200aresulting in ][ syntax. It creates a compact, readable chain that\u2019s still easy to debug since you can execute it piece by piece. I prefer succinct code, but that\u2019s just my style\u200a\u2014\u200ause whatever approach works best for you. We can write code in one line, or multi-line, with logical\u00a0steps.<\/p>\n
On one of the plots we look at a date, when each product was first seen. To get that date, we set a key on date, and then take the first occurrence date[1] per each base_product.<\/p>\n
#-- versions per year, product, with a date, when it was 1st seen x3c_dt <- x3_dt[, .N, .(base_product, variants) ][, .(variants = .N), base_product][order(-variants)]
The resulting table is exactly as we need it for charting.<\/p>\n<\/figure>\n
The second plot uses transaction date, so the data wrangling is similar, but without date[1]\u00a0step.<\/p>\n
If we want to have a couple of plots combined, we can produce them separately, and combine using for example ggpubr::ggarrange() or we can blend tables into one dataset and then use faceting functionality. The former is when plots are of completely different nature, while latter is useful, when we can naturally have combined\u00a0dataset.<\/p>\n
As an example, few more lines from my\u00a0script.<\/p>\n
plot_04_w <- x3h_dt |> ggplot(aes(year, total_products, color = variant_bin, fill = variant_bin, group = .id)) + geom_col(alpha = .8) + theme_bw() + scale_fill_viridis_d(direction = 1, option = \"G\") + scale_color_viridis_d(direction = 1, option = \"G\") + labs(x = \"\", y = \"Base Products\", title = \"Products, and their variants\", subtitle = \"Yearly\", fill = \"Variants\", color = \"Variants\") + facet_wrap(\".id\", ncol = 2) + theme(... other styling options)<\/pre>\n
Faceting has massive advantage, because we operate on one table, which helps a lot in assuring data consistency.<\/p>\n
Pareto<\/h4>\n
The essence of Pareto calculation is to find how many products do we need to achieve certain revenue percentage. We need to prepare the dataset, in a couple of\u00a0steps.<\/p>\n
In case we\u2019d need to mask exact product names, let us create a new variable.<\/p>\n
#-- products name masking x3a_dt[, masked_name := paste(\"Product\", .GRP), by = base_product]<\/pre>\n<\/figure>\n
And dataset printout, with a subset of\u00a0columns.<\/p>\n<\/figure>\n
And filtered for one month, showing few lines from top and from the\u00a0bottom.<\/p>\n<\/figure>\n
The essential column is cum_rev_pct, which indicates cumulative percentage revenue from products 1-n. We need to find which prod_n covers revenue percentage threshold, as in the pct_thresholds_dt table.<\/p>\n<\/figure>\n
So we are ready for actual Pareto calculation. The code below, with comments.<\/p>\n
#-- perform a rolling join - crucial step! x3b_dt <- x3a_dt[, .SD[pct_thresholds_dt, roll = -Inf], month][, ..sel_cols]<\/pre>\n
Why do we perform a rolling join? We need to find the first cum_rev_pct to cover each threshold.<\/p>\n<\/figure>\n
We need 2 products for 20% revenue, 4 products for 30% and so on. And to have 100% revenue, of course we need contribution from all 72 products.<\/p>\n
#-- charting plot_07_w <- x3b1_dt |> ggplot(aes(month, prod_n, color = cum_rev_pct, fill = cum_rev_pct)) + geom_line() + theme_bw() + geom_area(alpha = .2, show.legend = F, position = position_dodge(width = 0)) + scale_fill_viridis_d(direction = -1, option = \"G\", begin = 0.2, end = .9) + scale_color_viridis_d(direction = -1, option = \"G\", begin = 0.2, end = .9, labels = function(x) scales::percent(as.numeric(as.character(x))) # Convert factor to numeric first ) + ... other styling options ...<\/pre>\n
Lorenz curve<\/h4>\n
To plot Lorenz curve, we need to sort products by it\u2019s contribution to total revenue, and normalize both number of products and\u00a0revenue.<\/p>\n
Before the main code, a handy method to pick n-th month from the dataset, from beginning or from the\u00a0end.<\/p>\n
The code is straightforward here, assuming sufficient prior data preparation. The logic and some snippets in the main body of this\u00a0article.<\/p>\n
Streamgraph<\/h4>\n
The streamgraph shown earlier is an example of a chart that may appear difficult to render, especially when interactivity is required. One of the reasons I included it in this blog is to show how we can simplify tasks with keys, joins, and data.table syntax in particular. Using keys, we can achieve very effective filtering for interactivity. Once we have a handle on the data, we\u2019re virtually done; all that remains are some settings to fine-tune the\u00a0plot.<\/p>\n
Since we want joins performed monthly, it is good to create a data subset covering one month, to test the logic, before extending for a full\u00a0dataset.<\/p>\n
#-- test logic for one month month_sel <- as.Date(\"2020-01-01\") sel_a_cols <- c(\"month\", \"rev_pct\", \"cum_rev_pct\", \"prod_n\", \"masked_name\") x3a1_dt <- x3a_dt[month == month_sel, ..sel_a_cols]<\/pre>\n<\/figure>\n
We have 23 products in January 2020, sorted by revenue percentage, and we also have cumulative revenue, reaching 100% with the last, 23rd\u00a0product.<\/p>\n
Now we need to create an intermediate table, telling us how many products do we need to achieve each revenue threshold.<\/p>\n
#-- set key for join list(x3a1_dt, pct_thresholds_dt) |> lapply(setkey, cum_rev_pct)
#-- perform a rolling join - crucial step! sel_b_cols <- c(\"month\", \"cum_rev_pct\", \"prod_n\") x3b1_dt <- x3a1_dt[, .SD[pct_thresholds_dt, roll = -Inf], month][, ..sel_b_cols]<\/pre>\n<\/figure>\n
Because we work with a one-month data subset (and picking month with not that many products), it is very easy to check the outcome\u200a\u2014\u200acomparing x3a1_dt and x3b1_dt\u00a0tables.<\/p>\n
And now we need to get products names, for selected threshold.<\/p>\n
#-- get products #-- set keys list(x3a1_dt, x3b1_dt) |> lapply(setkey, month, prod_n)
And verify, for the same month as in a test data\u00a0subset.<\/p>\n<\/figure>\n
If we want to freeze products for a certain month, and see revenue from them in the whole period (what second streamgraphs shows), we can set key on product name and perform a\u00a0join.<\/p>\n
And we get exactly, what we\u00a0needed.<\/p>\n<\/figure>\n
Using joins, including rolls, and deciding what can be precalculated in a warehouse, and what is left for dynamic filtering in a dashboard does require some practice, but it definitely pays\u00a0off.<\/p>\nImage generated by DALL-E, based on author\u2019s prompt, inspired by \u201cThe Bremen Town Musicians\u201d<\/figcaption><\/figure>\n
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Afc3aEYB3InUBz1IgfXGFtA.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Ay43-dSaq6CDyS199Y7sDaw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Ak1b8DIQG-h76T5mvsyuXsQ.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Ach7oF2keDcCoQ6gzE0c3Bw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AnArp6wNLllnrf2S1y5p-gA.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AITy37GAbGtmB_HDyPYBAIw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/340\/1%2ApSKS6UCeEO4qgcx4WsBbZA.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AvEwXiTaYv3FZfZpNBwKymQ.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AvVqu8_U3-8wr3ffTSEcUZg.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AOeEkn91odOdGXEp6zaeHNg.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AdYR5EHAK-bGtkXtzCe4Q2w.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Aba_RTnDMuR85j4b2CsstHQ.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AReycwUGFFZ-_8KLWaohERw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/252\/1%2ALKhVbIWbaoGXl8sJjyxNkw.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A9CimWZmU2eqdNGRNW89oJQ.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A95EgMTxRiFtVDWeAhbUjSw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A1yGLMQ3zbEYErqdfYthQ9g.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A1oLSyYXq5Eh9-bCDeOesqQ.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A9zcGxwJX7S25viHBFKbg4A.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/566\/1%2AInr7l_VcHVZ06golm7617w.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AtmHk8wkHqUxRy7hqyKzn0A.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/800\/1%2AiyvX_gR04Kfv7t1ahCc6KA.jpeg?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2As1ctrG2MEWkMYWyRtjOtHA.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Ae8ZHqjLaijjb899rKiqRWw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Ao235vagWj4DgV5wAU22JEQ.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A9d3PGlyU3c7BGbwpkXTGKw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2ANY0rj41RpxDXdtECXz-Ykw.png?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Azy7rfApUuDEUhyX9UGfxtQ.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AaPOuZvk3rrOR9j89VLpiAw.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A5GCjLL37Bjv5oZVT3sfpoA.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AaX9j3L4UjJbQLrZyb7HeZQ.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AWlKAv8CwioGfl_q1yf4fTw.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AGbIeipanxC15SQGKoRWVVg.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A2_SeZMFX0b-L1H6Q6ELmEA.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AxMvF8pIgpnzTp6iLnkkmhg.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AOCNYsMDvAs0NxFmN4b43Ng.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AhiMmEfB5ulXitoyqiFyqRA.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AlYeG09CtMzUeVqHhsaqNfw.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2Arg-afsXUM77JY4tVMspyvg.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AxJO-Q3hCcC92WDgRWNAmJg.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AqM7tovjciF1EH1MVwEUG2A.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2A0P1WNBScfSivJ7aQf9vdcg.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AQqXWWKuGlz02iDeE0stYcQ.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1024\/1%2AOWFvf02hi4_YY9Q5OneNaw.png?ssl=1\")
<\/figure>\n![\"\"](\"https:\/\/i0.wp.com\/cdn-images-1.medium.com\/max\/1022\/1%2AvC4zfvenDCAZ18zh7KtacQ.png?ssl=1\")
![\"\"](\"https:\/\/medium.com\/_\/stat?event=post.clientViewed&referrerSource=full_rss&postId=adc3d0876acd\")
<\/p>\n