Different Paywalls for the same offering

Hi ​@kate-w,

The relation we have for paywalls is 1-1 for offerings, each paywall is related to one offering. You can duplicate offerings - which would duplicate the paywall - and change the text details you need. This way you could A/B test different paywalls just changing the offering id. You can also use targeting in that case, you set up a placement id that you pass on your getOfferings and you’d get the products and paywall defined for that specific placement.

Let me know if this helps!

what’s the driving force for having the 1:1 relatioship between offering and paywall? 

offerings have a huge amount of underlying package/product config going on - the paywall is simply their presentation. surely you’d want to have an easy way to present the EXACT same set of packages in various ways to test things? duplicating the entire offering feels very heavy handed and starts to introduce all sorts of complexity around ensuring changes to the offerings are in sync across all paywalls, offering ids are maintained in code (yes, I know about targeting, but it’s complicated...).

allowing 1:n offering:paywall would allow for easier small tweaks to the design without touching/impacting the complex underlying nature of offerings; while still allowing for offering duplication if one actually wanted to test variants of that.

am I missing some benefit / limitation at a store level that makes this the best route? I’d like to make sure i’m architecting my app correctly to take advantage of the v2 paywalls.

thanks!

Hi ​@andrew23,

Thanks for the feedback! The main reason is due to experiments. Offerings are very inexpensive and you can duplicate them very easily. The idea is that an offering is a set of subscriptions you want to sell, and those always go on a paywall so it makes sense that an offering has a paywall attached. At the same time, this is really useful for A/B testing paywalls with different prices and also to use targeting. When you fetch an offering you know which paywall is attached to it, if you had n paywalls per offering and n offerings it’d be a mess to identify which paywall is performing better or worse. Also then your experiments wouldn’t be valid since maybe what performs best is the paywall wording rather than the pricing.

Best,

Thanks for the insight ​@joan-cardona, however I don’t agree this makes things easier… please hear me out:

Testing should (probably) cover two main areas: paywall design and pricing (via offerings). These are arguably the two most important factors that influence conversion (source: every bit of marketing and sales advice available).

This means we need to be able to show multiple paywall designs easily to test which converts best while also being able to surface different pricing/package combinations (offerings). You’re right that this can get messy, but ideally you’ll be doing one set of testing at a time. 

While running design tests, you keep the offering stable but use various paywall designs.

While running pricing/package tests, you keep the design stable while varying the pricing (via offerings).

The tooling should make both of these simple. Today I argue it doesn’t.

The current system makes it very hard to manage multiple paywall designs - after duplicating the paywall, if I have to make a change, I now need to do my design changes many times over. Ensuring the designs remain identical is very time consuming - and critical when the test is for different pricing. 

What also hard is that if I have a design I like, I can’t just copy it and start using it for an existing offering. You may argue I should just create a new offering - but this means I have to go find all my targeting rules and placements and make sure they’re updated.

I know this is beta, but I think the team need to take a much closer look at what’s going on here. I don’t think the model you’ve chosen maps accurately to the problem domain. The likes of Superwall are far closer to an ideal solution - but also have issues.

Ultimately, my take is that you should have something closer to these domain entities:

• offering - describes the packages/pricing as it does today
• design - the UX used to present an offering using a certain layout/messaging. they live independently of everything else. a single design can be used in multiple paywalls (an offering needs to be hooked up to the design such that packages map correctly)
• paywall - the combination of an offering and a design that the user sees, presented at the correct time. a paywall has a single offering and 1+ designs. conversion stats live at this level. this is the entity referenced in targeting rules. a single design can be used in multiple paywalls with different offerings to test pricing performance.

Again, if I’ve missed something, or there’s work going on behind the scenes, sorry! :) I really just want this to be amzing and useful - and right now, I’m battling.

Thanks!

Thanks so much for the thoughtful write-up! 

The tooling should make both of these simple.

We agree

Today I argue it doesn’t.

Totally fair

Again, if I’ve missed something, or there’s work going on behind the scenes, sorry! :) I really just want this to be amzing and useful - and right now, I’m battling.

And no apology needed. :)

This is a topic we’re focused on improving, and I’d love to hop on a call to chat more about this and get into detail on the pain points you’re running into. There are a few different ways we could solve it that we’ve discussed and understanding which parts of the setup/management/testing process cause the most friction today is very helpful as we do that.

I’ll message you each individually to see if you’d be up for hopping on a call to share more feedback and hear about the solutions we have in mind, but absent that we very much appreciate the feedback here!