Create a Corrily Coupon
Create coupons on the Dashboard or with the API **Creating a coupon on Corrily Dashboard:** * On the Corrily Dashboard, open the Coupons page. * Click "Create Corrily Coupon" * In the dialog, enter the coupon parameters * Click Create coupon. Alternatively, you can also import coupons from other systems such as from Stripe or Chargebee. This creates and maps corresponding Corrily coupons. *** Here are all the **settings for coupons** that Corrily supports right now: * **Name:** The name of the coupon that appears on receipts and invoices * **API ID:** A unique identifier for the coupon in the API. Corrily auto generates this for you, but you can also change it to your liking * **Type:** Determines whether a coupon discounts a subscription by a fixed amount or by a percentage * **Value:** Percentage off or Discount amount * **Currency:** currency for Fixed Amount coupons We will soon be adding support for `coupon expiration`, `coupon targeting` (i.e. certain coupon codes can only be applied on certain products for e.g.), # How to Design Experiment Source: https://docs.corrily.com/experiments/01_experiment_design How to target the correct subset of users to experiment on. Corrily allows users to design and run [various types of experiments](/experiments/02_experimentation_platform). This article will describe the general experimentation framework, guide you through the process of setting up and running any type of experiment, as well as analyzing the results and taking appropriate actions after the experiment was concluded. ## From Hypothesis to Experiment Design Before running an experiment, it is important to **outline what hypothesis you want to test**. This could mean running a single experiment or it could mean breaking down the hypothesis into multiple experiments. For e.g. if your hypothesis is that there may be **higher willingness to pay for your products in North America**, you may want to break down the hypothesis into two experiments - one experiment across US and Canada (since they are likely similar markets for your business), and another for Mexico. If your hypothesis is a little more specific - say, there is higher willingness to pay amongst *professionals in North America*, it is best to [**define the relevant audience**](/segmentation/01_audiences) on the Corrily dashboard, and segment your experiment further. However, if you do not have a strong hypothesis, we recommend starting broad, learning from the experiment analytics so you can form some hypothesis, and then running more specific experiments. Other important consideration when designing your experiment is to think through [**what cohorts of users do you want to experiment on**](#experiment-policy). Do you want to experiment solely on new users who have never seen your pricing page before, or you want to experiment with just the free user base. There are all important considerations in deciding who to experiment on and setting your experiments up for success.Why use Corrily for your pricing, packaging, discount and paywall experiments?
Corrily provides an end to end experimentation platform for all things pricing, packaging, discounts and paywalls. Corrily's experimentation platform abstracts the complexity involved in running experiments in-house, and manages everything for you. Moreover, our **machine learning models are pre-trained, and continuously improving** over time based on your business-specific data and anonymous data across our entire customer base. This, in combination with our **data-efficient sampling algorithms**, results in **30-40% improvement** in experiment convergence over traditional AB/n experiments.What can you manage using Corrily's experimentation platform?
Experiments in Corrily can be set-up and managed using our dashboard or the API: * Defining the experiment objective * Managing control and experiment treatments * Orchestrating experiments i.e. traffic allocation, adding and disabling particular experiment treatments * Measuring experiment results across most common metrics such as ARPU, LTV, Conversion, Retention, MRR, ARR etc. * Calculating statistical significance and Confidence Intervals * Post-experiment clean-up * Rolling out winning experiment treatmentsDifferent types of Experiments in Corrily
Corrily's Experimentation platform allows you to run various kinds of experiments. * **Pricing Experiments:** to find the best price for a set of users. Pricing experiments can be used to test different price points, different strikethrough prices, as well as price formatting i.e. price rounding strategies and currencies shown * **Packaging Experiment:** to find the best combination of products and plans for a set of users. Packaging experiments can also be used to test things such as different feature combinations for a product, different trial strategies etc. * **Discount Experiments:** to find the optimal discount for a set of users. Discount experiments can be used to test optimal discount percentages or amounts or couponsThings to know before setting up an experiment
A few things to note while running an experiment with Corrily: * **Experiment Objective:** Corrily supports various experiment objectives that you can choose from, such as Optimizing ARPU, LTV, Conversion or Retention. Make sure you are selecting right experiment objective * **Experiment Targeting:** Experiments can be run on a subset of products, countries and audiences. We recommend spending some time thinking through the experiment architecture, especially if you plan on running multiple experiments. At Corrily, our Pricing and Data Science experts are more than happy to consult. * **Experiment States:** An experiment can have multiple states: `Draft`, `Ongoing`, `In Review`,`Paused` `Completed`. You can set-up an experiment in the `Draft` state, submit it for `Review` before going live. Once an experiment is live, you can decide to `Pause` an experiment (say during critical business periods), and `Resume` it later. Experiments can move to a `Completed` state when they reach desired statistical significance, or can be forced to end subjectively * **Traffic Allocation:** Experiment traffic allocation can be manual or dynamic i.e. optimized automatically by Corrily's machine learning models * An experiment in Corrily does not necessarily need to have a control group # Experiment on Prices Source: https://docs.corrily.com/experiments/03_price_experiments How Corrily runs price experiments.What is Price Experiment
In the Corrily platform, there exists a [variety of experimental techniques](/experiments/02_experimentation_platform). The most common of them is **"Price Experimentation."** This methodology allows for the systematic variation of prices and currencies displayed to different users, even when considering the same subscription plans. Essentially, every user will view the same range of plans, but the prices for each plan, or a subset of them, may differ. ### Key Applications of Price Experimentation: 1. **Baseline vs. 10% Increase**: This experiment can be designed to compare the baseline price with a price that's increased by `10%`. This provides insights into user behavior and purchasing decisions when exposed to a minor price hike.How to setup Price Experiment
### 1. **Select Experiment Products** Upon naming your experiment, the subsequent step is to determine the products that will be part of the experiment. This could encompass various subscriptions or packages, ranging from monthly to annual durations or from basic to advanced offerings. These product definitions are located in the 'Products' tab of our dashboard. For a comprehensive guide on product creation and management, refer to [Products documentation page](https://docs.corrily.com/prices/07_products_configuration). ### 2. Add Arms and set prices for Experimental Arms Corrily experiments utilize the concept of arms. Think about it as about "AB tests on steroids". Experiment will have a couple of arms to test, which should include the single baseline arm to compare with. For any arm except baseline you would need to change prices and/or currencies. This price changes could be done in the Experiment Setup Interface, similar to Price Control Center. Here you can use bulk actions to modify the prices and can change prices for each country / audience individually. In our example, we are starting a new experiment, and after filling the first page of information related to the experiment we reach the Define Arms step. Here we have a Baseline arm and we need to add at least one more to be able to proceed. Note that if you wish to delete the Baseline arm you can do that but you need to set another added arm as the new Baseline.Corrily as a Recommendation engine
Running Corrily as a Recommendation Engine for your prices as well as products is really straightforward: * Instead of integrating prices returned by Corrily on your pricing interface, you can call Corrily in parallel with your regular pricing flow. * You would still be calling Corrily's APIs every time a price needs to be fetched, and pass all the relevant information i.e. `User IPs`, `User IDs`, `Product IDs`, `Country`, `Coupons` and any additional user characteristics such as device, acquisition channel etc. * Corrily's recommended price can now be stored as an ephemeral price and displayed based on certain business logic at your end * You would still be feeding revenue events to Corrily using pertinent integration options for you Here is an illustration of how the end to end flow would look. **Note:** If you are using Corrily to optimize your paywall (i.e. optimizing which plans and products to display), you would still be following the same set of steps.## Corrily Roles Corrily's dashboard supports role-based access so you can invite team members to the dashboard without worrying about giving users (such as those on your support team) elevated privileges. Giving only the required level of access for a user mitigates security risks and makes it easier to stay compliant with company policies. Because we understand that not every user in your organization needs full access to the Corrily dashboard, we support four distinct user permission groups with varying levels of access: `Admin`, `Member`, `Support`, `Support(read-only)`. Currently, there is no hard limit on the number of users you can invite to the dashboard. * **Admins:** Admins have access to the entire dashboard, including the ability to change prices, start/pause/stop experiments, add/remove users from the dashboard, as well as change their roles. Admin role is recommended for anyone who needs to make changes to the pricing using Corrily's platform - such as pricing managers, business planners, product and growth team members etc. * **Members:** Members have read-only access to the entire dashboard. While members cannot start/stop experiments, they can review experiment results, search and interact with prices * **Support:** Support role is useful for customer-facing support team, such as L2 or L1 support. Support team members only access to the `Users` page on the dashboard. On the Users page, they can look up users by keying in their *User IDs* (internal to your system), and override the price and currency. This is helpful in edge cases where a particular user may have been served a price that they were not expecting, and subsequently create a support request. Instead of escalating the request to their pricing team, support team members with the right privileges can assign them another price. * **Support(read-only):**: Read-only support roles is best suited for L3 support.They also have access just to the `Users` page on the dashboard. They can key-in *User IDs* to look up prices for specific users, but cannot change those prices. # Paywall JS SDK Integration Source: https://docs.corrily.com/integrations/02_paywall-integration Use Corrily SDK to render a complete Paywall with plans & prices coming from Corrily Corrily no-code [Paywalls](/paywall-builder/configure) are used to minimize effort required for Pricing Page implementation by providing ready-to-use front-end Paywall component. Simply install Corrily SDK and render the complete paywall with a few lines of code.
{product.name}
{previousProduct && {previousProduct.price}}
{product.price}
Features:
-
{product.features.map(feature => (
- {feature.name} ))}