 IntroductionIn this post, we will explore the implementation of Retail Calendars in Looker and delve into the advantages they offer. We will focus on how to leverage these calendars to build scalable Period Over Period (PoP) comparison functionalities. This includes importing retail calendar data into a Looker view, extending the view, and creating new dimensions to enable seamless period-based analysis. We will also cover how to join these calendars to explores, ensuring flexibility in reporting. Additionally, we will walk through implementation details with code snippets and provide comparison examples to illustrate the impact of these techniques.
By the end of this blog, you will have a robust, user-friendly solution to perform powerful period comparisons, such as analyzing a Retail Month against the same month in the previous year.
0 Comments
 Introduction
In this article, we’ll walk through how to implement Period Over Period (PoP) comparisons in Looker. While Looker suggests a few approaches for comparing different time periods, we will introduce a customized approach developed by our team at Nupanch. Our approach highlights enhancements that can be made to Looker’s suggested methods. This guide includes code snippets and example outputs, so you can easily replicate these techniques in your own Looker instance.  One of the biggest problems that eCommerce companies face is inventory management. Having too little or too much inventory for a product lowers profitability. Lack of inventory can also mean a lost customer.
There are many solutions for inventory management today. Most of these focus on forecasting sales for existing products or newer versions of existing products. There are fewer and less proven methods for forecasting sales of completely new products. And understandably so - without any historical sales data for comparable products, it is more intuition than science. You get your hands on a new data set. The goal - to get a deeper understanding of a specific phenomenon, say churn. You do the due diligence - eyeball the data to see what data points it contains and prepare some basic summaries (averages, medians etc.). Then you start asking questions of the data to get a better understanding of churn.
However, after building out a few reports, nothing stands out. The behavior of users who end up churning seems very similar to users who renew. Their interactions with your product/service are not very different. Customer support metrics are equally positive. This leaves you confused and a bit apprehensive. If there are no visible differences or indicators, how do you optimize renewal? Remember the first time you saw a large SQL query written by somebody else? I do. Meaningless aliases, no comments, all sub-queries and no common-table-expressions. Almost zero readability. What’s worse is that I had to debug this query because it was resulting in a discrepancy. Where on earth do I start?
 Many eCommerce companies calculate Customer Lifetime Value (CLV) as the sum of all historical purchases for each customer. However, CLV, by definition, is a forward-looking statement. By simply considering historical purchases, the underlying assumption is that the customer will not make any further purchases. There has been significant statistical research into creating reliable probabilistic models to calculate Residual Customer Value (RLV) i.e. the dollars your customers are yet to spend.
 The short answer is Yes. Heck Yes. At some point during an e-commerce company’s growth, teams begin to organically form, and team members begin asking “why” and “how many” questions. This often happens when new customers are being acquired, and it’s not easily clear where they came from. You’re no longer measuring marketing ROI by the revenue that came in during the campaign only. Now you’re looking at customer lifetime revenue as the “return” part of the equation.
 The Magento EAV structure is one that is designed for scalability, but loses efficiency when it comes to data analysis. Due to the use of multiple tables for storing the “entity”, “attribute” and then the “value”, a SQL query to perform complex product analyses is required to perform joins across several tables. This article outlines an approach to “flatten” this structure so that all products and their associated attributes are stored in the same table, allowing for easy analysis.
 In July 2016, Magento acquired RJMetrics, a business intelligence platform designed primarily for e-commerce analytics. This product has now been branded as Magento Business Intelligence, offering a full stack BI product to Magento merchants.
|
Archives
December 2024
Categories |
RSS Feed
Data migration icon used on the home page is by "unlimicon" from The Noun Project.
Report building, account cleanup and data structuring icons used on the home page are by "Dinosoft Labs" from The Noun Project.
Getting the most out of icon used on the blog page is by "Luis Prado" from The Noun Project.