[HN Gopher] Launch HN: Corrily (YC W21) - Price Optimization for...
___________________________________________________________________
Launch HN: Corrily (YC W21) - Price Optimization for SaaS
Hi HN! We are Abel [abelr] and Andrej [neophocion] of Corrily
(https://www.corrily.com/). We're building a price optimization
service for subscription and usage-based companies. By wrapping our
API around the prices you display on your frontend and integrating
with Stripe, we allow you to experiment with your pricing and find
optimal prices, and localize them to the user's country. When we
met, we were both quants, and Abel was focusing on price-formation
and market dynamics for a hedge fund (this was before WSB became
the authority for price-formation). We got along well, did weird
side projects such as parsing 17th Century newspapers and throwing
them at NLP models, and decided to launch a startup. Before getting
accepted into YC we were working on a slack bot of all things. We
probably got into YC, in part at least, thanks to this HN post
(https://news.ycombinator.com/item?id=24886936) which made it to
the top page a day before our interview and allowed us to get
around 60 leads. But we had trouble pricing our service. So we took
a deep dive into how businesses do it currently, and were...
underwhelmed. Surveys! Whether Van Westendorp [1], Conjoint
analysis [2], or Gabor-Granger [3], pricing generally involves
sending out surveys to people asking how much they would pay for a
service. It's expensive (a Simon-Kucher engagement will cost you in
the high 6-figures), time-consuming (~9 months), and based on ex-
ante perception rather than empirical evidence. We strongly
believe in charging a fair price, inclusive of the purchasing power
of each country. And it also makes economic sense. But because it
is so hard to do price-experimentation, only large companies can
adapt their pricing per country. Right now, a slack plus seat costs
$12 in the US and $6 in India. Netflix's monthly subscription will
range from $3.75 in Argentina to $19.12 in Switzerland. So we
dropped the chatbot and built Corrily! Subscription pricing has an
interesting psychological dimension which makes the prices you
display linked to each other. The price of your first tier will
influence the conversion rate of your second tier, and the annual
discount you give will influence the conversion rate of your
monthly subscription. Our favourite example of the psychological
dimension of pricing is described in Predictably Irrational by Dan
Ariely. The Economist for a while had 3 subscriptions: an online
subscription for $59, a print subscription for $125, and an online
+ print subscription for $125. The reason to add this odd print
subscription was because it reframes the difficult question in the
purchaser's mind from "how much am I willing to pay for The
Economist?" to the much easier question "Which of these offers is
the best bang for my buck?". The way we solve this is by testing
all prices at once using Bayesian Optimization. We continuously
measure the RPV and LTV of users based on the set of pricing they
are shown. We briefly experimented with multi-armed bandits to
decide when to show a user an experiment, and found that quant
finance techniques used for trading ETFs at VWAP perform much
better. Corrily is easy to use and integrate with. Here's our
developer portal with some easy-to-use docs to get you going
https://doc.corrily.com . Let us know if you're interested in a
test API key. We've seen early signs of companies growing their
conversion rates by >30% as a result of integrating Corrily. It's
not something we're prepared to shout from the mountaintops just
yet, but it is a sign that there are many mispriced prices out
there. We're here to try and fix that. We're long time fans of HN
and have grown up reading it. Any and all feedback or criticism is
greatly appreciated. Thanks ~ Abel and Andrej [1]
https://en.wikipedia.org/wiki/Van_Westendorp%27s_Price_Sensi...
[2] https://en.wikipedia.org/wiki/Conjoint_analysis [3]
https://en.wikipedia.org/wiki/Gabor%E2%80%93Granger_method
Author : abelr
Score : 51 points
Date : 2021-03-01 12:43 UTC (10 hours ago)
| lancesells wrote:
| A/B testing of pricing isn't new but I wonder if you ever
| question if this is an ethical business to be in? I know
| capitalism is about extracting the maximum value out of
| everything but do you think it's a worthwhile pursuit to make
| this an even easier thing for companies to do?
| fastball wrote:
| If something isn't more valuable to you than its price, why
| would you buy it?
|
| If $Y > $X and $Y < $VALUE_TO_YOU, how would it be unethical to
| optimize prices to find $Y?
| lancesells wrote:
| That's a good question and I'm not sure I'll have an answer
| for you but I'll try and explain my thought process. I look
| at technology similar to this (this seems more benign than
| some) as extracting as much value from people as possible.
| It's not a question of "what can I charge to live comfortably
| and have a great life" but how can I extract as much revenue
| as possible from my customers.
|
| The big companies are masters of this and continue to get
| better as computing gets faster. It worries me a great deal
| that everything is or has become a monthly payment in
| perpetuity.
| neophocion wrote:
| Kyle Poyar [1] has a great article [2] on why usage-based
| (i.e. having that monthly payment change with usage) is
| more optimal (and arguably more fair).
|
| In some deeper sense though, I commiserate with your point
| on technology being alienating through its strive to over-
| optimize everything. Except, I think much of this friction
| will inevitably have to be solved by further application of
| technology itself -- it's always a double edged sword..
|
| In our case, as Abel explained, one of the things we're
| trying to solve are very apparent international
| mispricings.
|
| Growing up in post-communist E Europe in the 90s I remember
| buying pirated games from street vendors. An unawareness of
| international pricing can easily price out many a potential
| client! :)
|
| [1]: https://twitter.com/poyark [2]:
| https://techcrunch.com/2021/01/29/subscription-based-
| pricing...
| abelr wrote:
| So I am super interested in your comment and I think you will
| be a bit surprised by my response. I am not a strong believer
| in capitalism. On the contrary. Neither is Andrej. We both grew
| up in leftist families and I must have been the only portfolio
| manager that reads Das Kapital at night. We actually came at
| the problem from a very very different direction. We thought
| pricing everything from a US perspective was problematic. The
| price levels in India are about a 10th of the US. So we thought
| "Ok but that doesn't even make sense for a SaaS to price the
| same way everywhere. Because they lose out on poorer markets".
| We built Corrily with the thought that more personalized
| pricing based on an individual's willingness to pay also
| reflected an individual's capacity to pay.
|
| We think it's pretty cool to align a business incentive (reach
| more markets) with an economic one (poorer nations and richer
| nations paying different amounts).
|
| I actually wonder a lot what other people think about this
| because I think it is an important point. Is it fairer to price
| differently according to willingness to pay given not everyone
| has the same purchasing power, or to give the same price to
| everyone?
| lancesells wrote:
| Thanks for the response. It's definitely a tough question on
| what is fair.
| hellojason wrote:
| I'm curious of the legalities of price testing. VWO suggests [0]
| never offering the "exact same product" at a different price for
| legal reasons. Your service doesn't appear to change plan
| benefits or names, only prices.
|
| [0] https://vwo.com/blog/ab-testing-price-testing/
| abelr wrote:
| I'd be curious to get examples of actual successful lawsuits
| resulting from A/B testing! Regarding the legality of it, in
| the US it is illegal to perform price discrimination when the
| intent is to directly harm your competition ([1], [2], [3]).
| However, first, Robinson-Patman does not apply to services [4],
| and secondly this is trying to avoid predatory pricing, and the
| supreme court ruled that price differentials are prohibited
| when the price differential "may be substantially to lessen
| competition". Similarly in the EU, Article 102 c) of the Treaty
| on the Functioning of the European Union prohibits price
| discrimination for companies in dominant position. It has
| however been significantly relaxed in United Brands v.
| Commission [5], where the court recognized that a dominant firm
| may charge different prices to reflect the competitive market.
|
| In short, price A/B testing is legal and common practice for
| most companies, and VWO's article seems a bit too quick to jump
| to declaring it illegal.
|
| [1] https://en.wikipedia.org/wiki/Sherman_Antitrust_Act_of_1890
|
| [2] https://www.law.cornell.edu/wex/Clayton_Antitrust_Act
|
| [3] https://en.wikipedia.org/wiki/Robinson%E2%80%93Patman_Act
|
| [4] https://www.ftc.gov/tips-advice/competition-
| guidance/guide-a...
|
| [5] https://eur-lex.europa.eu/legal-
| content/EN/TXT/?uri=CELEX%3A...
| Chris_Newton wrote:
| You might also like to look into the EU consumer protection
| rules, particularly the Consumer Rights Directive and its
| respective implementations in the member states and the UK.
| There is quite a lot of specific information that must be
| provided to customers during the buying process, and there
| are some serious penalties available if a merchant is found
| not to have done so.
|
| In particular, if a customer might have seen multiple prices
| for the same thing around the time of purchase, for example
| on a pricing page checked on a phone and then on a checkout
| process completed on a PC, you would surely want to have
| solid evidence that the actual price charged had been clearly
| understood and accepted at the time of payment.
| abelr wrote:
| Absolutely! I remember reading this paper [0] about
| personalized pricing. The fact that personal data (an IP)
| is being used to inform prices has to be disclosed in the
| GDPR disclosure of a website. A very simple way to avoid a
| lot of those issues however is to have time-limited
| experiments in which 100% of Country's flow is directed
| towards one experiment (in the case of Corrily we keep
| track of which user saw what price when to insure the user
| will always see the same price).
|
| [0] https://www.econstor.eu/bitstream/10419/205221/1/de-
| Streel-J...
| edotrajan wrote:
| Please check. Got below response from chrome
|
| This site can't be reached www.corrily.com took too long to
| respond.
| abelr wrote:
| Oh that's odd! It's hosted on webflow... Is it still not
| working for you?
| abelr wrote:
| We asked a few friends to try from different countries and it
| seems to work, maybe try loading it again?
| aparsons wrote:
| Also timing out as of 9:28 AM EST on Firefox
| abelr wrote:
| We're switching on the Webflow CDN, hopefully that will fix
| it.
| timelincoln wrote:
| By the way if you're interested in experimenting more broadly
| outside of a stripe integration I wrote the quickstarts for
| Optimizely Full Stack which use a discount example, feel free to
| ask me questions about how it works :) (we have a free plan too)
| https://docs.developers.optimizely.com/full-stack/docs/javas...
| abelr wrote:
| That's a really neat quickstart! We actually allow to go
| outside of the Stripe integration and have an API to ping
| purchases here (https://doc.corrily.com/openapi/reference/opera
| tion/setSucce...)... But I wonder how to make it more user
| friendly. We did get a js SDK, but it wasn't very neat. Do you
| have any thought on what UX would make the most sense?
| gingerlime wrote:
| looks really interesting! we're a niche B2C with a global
| audience. We tried a bit of localized pricing in developing
| countries and synthetic currecies, but it seems tough to find the
| right price sweet spot. One odd thing we noticed was that
| localized prices don't necessarily convert better. perhaps the
| perception of a lower nominal dollar amount vs higher local
| currency? eg $20 might be nearly 1500 rupee which "feel" way more
| expensive?? (just our theory)
|
| What's the minimum conversion/traffic for running robust
| experiments?
|
| also how do you a/b test in the same country without risking
| people feeling lack of fairness?
| abelr wrote:
| The minimum would be 100 conversions per month below which we
| cannot perform experimentation. Obviously better works better,
| and 500 would be better. But even without experiments, we have
| default curves which you can use. Regarding A/B test, you do
| not need to A/B test in the same country, you can always
| perform experiments across countries and get 100% of the
| traffic of a country to the same experiment.
| gingerlime wrote:
| Thank you! this might be interesting for us. It won't be real
| A/B tests across different countries though unless they are
| extremely similar, right? our service is also seasonal and
| different countries are on different schedules so it makes
| even more of a difference I imagine.
| abelr wrote:
| The way we operate is by putting countries on a curve based
| on their characteristics (PPP, tech salaries etc.) and find
| which curve maximizes your KPIs. When you say seasonal do
| you mean yearly seasonality? I'd definitely be curious to
| hear more! My email: abel@corrily.com
| Chris_Newton wrote:
| Seems like an interesting and potentially quite valuable service,
| writing as someone who already has one business doing online
| sales and is currently working on a new one that also will.
|
| If you're looking for feedback, my immediate question would be
| how Corrily handles the issue of sales tax/VAT. This has become a
| big hassle particularly for B2C merchants already in places like
| the EU but increasingly around the world as governments decide
| they want their piece of the online sales pie.
|
| This might be relevant to a service like Corrily for two reasons.
| Firstly, as an anecdotal data point, we are only really
| interested in using payment services that handle the tax
| collection, remittance and reporting transparently at the moment.
| It looks like that would make it impossible for us to ever use
| Corrily since Stripe doesn't currently offer that functionality.
|
| Secondly, for a business that is starting to grow into
| international markets and starting to take issues like local
| purchasing power into account in its pricing model, there are
| going to be zones where the local tax rules mean the highest
| gross price isn't necessarily going to yield the highest net
| revenues. Maybe these windows are too short to be of interest to
| your target market or to be worth the effort to take them into
| account in your models, but instinctively it feels like the kind
| of technicalities that a service like Corrily ought to get right
| if the whole point is to identify and maintain optimal pricing
| for each local market.
| abelr wrote:
| We currently handle VAT for services (in this case we pass the
| correct VAT to send to Stripe via their tax rate API [1]). We
| have not yet expanded it to physical goods as they are a bit
| trickier to manage from a tax perspective. However you make a
| really good point on exploring this. I'd be curious to hear
| more about your experience actually, what were the biggest pain
| points you faced when growing internationally?
|
| [1] https://stripe.com/docs/api/tax_rates
| Chris_Newton wrote:
| Full disclosure: This experience is mostly gathered from a
| side business run by a small team in a niche market over a
| decade or so. I am probably a lot more "by the book" in how I
| like to run my businesses than your average startup founder.
| My personal experience and views may be atypical.
|
| Adding VAT to bills at local standard rates is only one small
| aspect of VAT compliance. You also have the actual reporting
| and remittance processes everywhere they apply. You might
| have some complications if any special rate applies to your
| product or service. Then there are the perennial questions of
| jurisdiction and extra-territorial enforceability, which I
| will leave to the lawyers and accountants because they make
| my brain hurt and I just want a definitive answer to what our
| true obligations are so we can comply with them. The worse
| part, particularly for a smaller business with no dedicated
| staff to work on this stuff, is how often the situation
| changes, sometimes at very short notice, and with no central
| authority you can monitor or that will notify you when you
| need to act.
|
| I have spent far too much time over the years updating our
| systems to get the implementation as close to exactly right
| as we reasonably can. I have spent even more time just
| watching things and trying to keep up with what our
| obligations were. The opportunity cost of that time alone
| must have been several orders of magnitude greater than the
| total difference in taxes ever collected and remitted as a
| result. That was, with hindsight, an absurd way to run the
| business. Being by-the-book, we should probably have just
| stopped all sales to the rest of the EU, which has only ever
| been a relatively small market for us, as soon as they
| introduced the more onerous VAT rules. (No doubt many
| businesses instead took a pragmatic view and simply ignored
| the rules and didn't comply, and I suspect few of them have
| suffered significantly for it in practice.)
|
| That is a lesson learned, and it's not a mistake I will make
| again. Fortunately, we don't have to, because there are now
| several services that will collect payments but also handle
| sales tax/VAT compliance transparently. Their value
| proposition appears compelling: we can sell everywhere, be
| fully compliant, and not be responsible for maintaining the
| implementation, all at the same time. So these services are
| where we are looking as we start the new business, and time
| will tell whether the reality meets expectations. I imagine
| that if we do settle on one and we are still happy with it
| after using it for a while, we will start using it for other
| businesses any of us run as well, and services like Stripe
| will move to a legacy role and ultimately be phased out
| entirely.
| javajosh wrote:
| _there are now several services that will collect payments
| but also handle sales tax /VAT compliance transparently_
|
| An interesting case of privatizing the enforcement of
| government regulation! But yes it does sound like a
| compelling value-add; note that this value is required by
| any world-wide marketplace, even the small ones, if they
| don't want to be at risk. It kind of sucks that VAT is like
| 20% but that's _still_ not enough to pay for a public
| version of one of those VAT compliance services.
| Chris_Newton wrote:
| Just my personal opinion now: I think VAT as a form of
| taxation doesn't fit into the modern global economy very
| well. VAT has long been criticised as a regressive tax
| anyway, but the basic principle of calculating value
| added by looking at the difference between the incoming
| and outgoing columns and then taxing that amount becomes
| difficult both to implement and to practically enforce if
| those columns fall in different jurisdictions. Then you
| end up with additional measures for cross-border trade
| that cause headaches for businesses and consumers alike,
| and you can create perverse incentives that punish
| businesses for trying to comply while rewarding those
| that do not with a competitive advantage. At the same
| time, we do live in that global economy now, and
| enforcing VAT domestically if you didn't try to impose
| analogous rules internationally would also cause a big
| competitive disadvantage for domestic suppliers.
|
| I don't know how you solve those problems without
| scrapping VAT entirely, with some profound implications
| for your entire tax system given how much tax revenue
| governments currently bring in this way that would
| presumably be shifted to other sources. (I can't help
| wondering whether removing VAT would also increase
| productivity enough by itself that it would offset at
| least some of the lost tax revenues automatically.)
| Whatever the plausible alternatives might be, it seems
| obvious to me that the current system doesn't work very
| well for anyone.
| neophocion wrote:
| Chris these are some fascinating points. If you don't mind,
| we would love to connect with you. My email is:
| andrej@corrily.com
| Chris_Newton wrote:
| You have mail. :-)
| CoffeePython wrote:
| Does this product work for non-SaaS products?
|
| I have a product[1] that teaches developers vim. It is a one time
| purchase. I've had many requests for purchase power parity.
|
| I'm currently using stripe checkout.
|
| Could I use your product to get dynamic prices for my product?
|
| [1] https://www.vim.so
| abelr wrote:
| Yes it does! I'll email you and we can get started if you want.
| We do price parity out of the box.
| CoffeePython wrote:
| Sounds good! Email is at the bottom of my product page,
| thanks!
| davidjgraph wrote:
| Interesting concept, I can imagine you're right about the amount
| of mis-pricing.
|
| The temptation would seem to be to run with your system for 12-18
| months and then turn it off once the numbers seem optimized. Do
| you expect that and how do you intend to combat it?
| abelr wrote:
| The usage really differs depending on the size of the company.
| For larger companies, they tend to have entire pricing teams
| and the pricing is never "Done". In this case we are adopting a
| subscription-based model and are trying to optimize prices in a
| very granular fashion (per country, tradeoffs between usage-
| based and subscription based fees etc.). Those customers tend
| to need experiments for the rest of their company's life.
|
| Then there are smaller companies. Think Seed or Series A
| companies that focus on getting prices in the right ballpark.
| For them, we provide a lot of value at first by finding the
| right price (and country adjustments) at first, and then
| provide a bit less value when they found prices that seem to
| work well. We adapted our pricing to reflect it with a low-ish
| subscription fee to maintain our infrastructure and show
| localized pricing to their users, and an experiment-linked
| usage based fee. We're happy with this system as it aligns well
| with the value we are providing.
|
| Later we will add dynamic promotions (think personalized time-
| limited promotions based on the user's usage of the app, or
| country holidays promotions) to increase conversions and help
| companies be local at scale, which should help us generate
| ongoing value, even to smaller companies.
| vincentmarle wrote:
| If you think about a supply/demand curve, picking one set of
| prices will always be suboptimal (and leaving surplus on the
| table), ideally you'd want to charge different prices to
| different groups of people to maximize your surplus. So if you
| think about pricing as a dynamic continuum, you can't easily
| "turn it off".
| [deleted]
| bttrfl wrote:
| Tough subject, also because customers hate price testing.
|
| There's a fascinating presentation by Jeremy Howard discussing
| dynamic insurance premium pricing:
| https://www.youtube.com/watch?v=vYrWTDxoeGg
| neophocion wrote:
| Just listened to this whilst eating dinner. I like his early
| point about how many data science projects fail because they
| fail to establish a clear value link. His points about pricing
| are similar to what we do but his are in a different context
| (insurance) and we're hoping to become much more of a turnkey
| solution.
| goodmattg wrote:
| I was responsible for implementing Conjoint, Van Westendorp, and
| Gabor/Granger for a certain well known survey company.
|
| A few thoughts:
|
| Conjoint isn't typically used for pricing, but for finding the
| attributes of products that maximize consumer desire / utility
|
| Conjoint is a hierarchical Bayesian method... so also Bayesian
| Optimization
|
| I like the idea of a continuous optimization via API rather than
| a survey, tightens up the feedback loop for smaller SaaS products
|
| You're going to want to get some academics to back your
| theoretical grounding - it's actually a sales thing if you're
| ever trying to sign larger contracts.
|
| There is no such thing as a "fair" price, just the market price
|
| How do you prevent users from feeling cheated when they realize
| someone else may get a different price? Or worse, just refreshing
| until they get the lowest price for the tier they want? This is
| probably the biggest sticking point of your service - larger
| companies probably can't get away with changing prices after
| launch.
|
| Congrats on the launch!
| abelr wrote:
| Regarding your last point on feeling cheated, there are two
| aspects to it. Right now if you check the price of Slack with
| an indian IP, you will see $2.67 for the lower tier (6.67 for
| the US), Netflix will give wildly different prices per country
| [1], and Survey monkey gives me the same USD price in Euros.
| People expect to pay different prices in different countries.
|
| The other aspect is to prevent a user from receiving different
| prices. To prevent that we do a few things. We remember the
| prices that were displayed to a user and can make sure an
| entire country gets the same prices during an experiment.
|
| [1] https://www.comparitech.com/blog/vpn-privacy/countries-
| netfl...
| mawise wrote:
| I would be very worried about customers finding out that
| other people in the same country got offered different
| prices. Here's an example of a story from the Atlantic[1]
| that describes it in a very poor light. Making sure someone
| always gets the same price on refresh doesn't hold up if they
| are browsing at a friends house for example. I would be very
| worried about getting shunned for price discrimination.
|
| [1]:
| https://www.theatlantic.com/magazine/archive/2017/05/how-
| onl...
| 0xy wrote:
| Then why does the airline industry thrive (recent events
| not included) with rampant price discrimination?
| aparsons wrote:
| In my experience, airline "price optimization" is wildly
| overblown a boogeyman tale.
|
| Airlines price classes of seats individually. If one is
| sold, the next user sees a different price. A rule based
| system is fairly common. They're not using RL or dynamic
| pricing algorithms. In fact, I'd wager most don't have
| the technical expertise or even data (with the rise of
| meta-search) to do so.
| abelr wrote:
| I think then the best is to experience in the entire
| country at once. There is no need to only experiment on a
| small percentage of users.
___________________________________________________________________
(page generated 2021-03-01 23:01 UTC)