Pricing Elasticity 101

Price elasticity is a wonderful equation.  When you Google it, you get a lot of equations that look like this:

E_d = \frac{\frac{P_1 + P_2}{2}}{\frac{Q_{d_1} + Q_{d_2}}{2}}\times\frac{\Delta Q_d}{\Delta P} = \frac{P_1 + P_2}{Q_{d_1} + Q_{d_2}}\times\frac{\Delta Q_d}{\Delta P}

Isn’t that the writing they found at Roswell, New Mexico on the Alien ships? I am also fairly sure I went to a party during my younger days at a house that had many of those symbols over the door. But that’s a different story.

To be honest, I think that might be way over complicating the simple idea of elasticity.

  

So much easier to think of it this way— if you think of elasticity in between these 2  graphs, all pricing should fall in there somewhere.

The simple math is if the price increase and unit fall behave in lockstep (or worse, units fall disproportionately to the price change), that’s elastic.  If the the units fall less than the price increase, that’s inelastic.  And that’s where the money lies.

Identifying these items is often difficult, as some degree of what-if has to take place. But in a perfect scenario and all other factors being equal,  if you raise price and units don’t fall (inelastic) then you make more profit.   If you raise prices and the unit fall % is greater than the increase in profit kept, your elasticity was too high, and you lost money.

The math is easy; the execution is what is actually much harder.  Consumer behavior is a fickle science, and small ripples cans make large waves.  If the consumers feel the price is too high for the situation (whatever that may be) they will not shop.  This applies to a grocery store, a web site, any transaction-based environment.

My concern is if the unit loss leads to intangible losses: What are the ‘pull items’ from a basket analysis that also may fall, with the law of unintended consequences rearing its ugly head.  If you raise cigarettes, and you gain extra money but lose units, and the change proves to be inelastic, that’s great! Units fell 2%, and transactions fell 2% but revenue and profit up 5%.  BUT- before you pat yourself, what about the sales WITH the cigarettes- Lighters? Gum/mints? Any change to behavior in these? Whats the avg UPT of a transaction involving the item. If the add-on item is not impacted greatly, or the net is still positive, that’s a winner.  The point is to look outside the box to be sure you are right and not just do analysis in a vacuum.   If the results of the total store, and the total transactions, and the total profit is increased, then the move was genius. Someone once said “Analytics Drives Business.” Enjoy the fruits of this! And then find the next inelastic item to glean profit from.  They are out there, filling your shelves, your website, your stock rooms.
Too low, too high, Goldilocks pricing?

Retail is an imperfect circle. Remember your 3 R’s- Right product, Right time, Right price- and all 3 factors are critical.  A great product late is no better than a bad product, and a incorrectly priced item negates the first 2 every time.

-THAT Planning Guy

 by

 

Weekend Update

A few things to comment for the weekend:
This week, in the same day, I said something was as ‘goofy as a left-handed join’. (if you don’t get that reference you may be on the wrong site) I also commented “Yo Dre, I got something to say”
I quoted Ice Cube and a SQL command in the same day.   It was THAT kind of day.
In the coming weeks, I will have a lot of things to say about BI and big data ‘tools. ‘ What does data mining look like? SHOULD it be easy?
I am thinking about the update to Replenishment 101 (201?) Where to go from simple? Complex!
Also, want to explore the pre/in/post season analytics: Living in 3 seasons at the same time.
Last, soon I want to look into size/color analysis: Best practice? Timing? Whats the best time to dig in the dirt to find the answwer?

“Somewhere squatteth the toad of truth.  ”

Stay tuned!

-THAT Planning Guy

PS- for my #datanerds:
SELECT *
FROM tablename1 LEFT JOIN tablename2
ON columnname1 = columnname2
WHERE condition