Simplified FairPayModel – Algorithmic Process

Richard Reisman

Working Notes 1/17/12, updated 10/17/18, 2/8/20

These are just rough, preliminary notes on a basic, proof of concept implementation of FairPay, intended to provide a concrete illustration of the simplicity that can be applied in its central algorithms. The algorithms here are just a reference point for design and development, using very simple rule-based logic and simple math. It is expected that skilled developers and marketing data analysts will readily design far more elegant and sophisticated variations on this theme, and that advanced solutions will apply AI/ML and sophisticated data science.

FairPay is a very flexible, and open architecture that can exploit advanced machine learning and predictive analytics and a richly nuanced user interface. It can be tailored to a wide range of use cases and platform environments with varying scope, objectives, and content.

These notes are supplementary to discussion elsewhere on the FairPayZone blog (see Overview and Selected Items). In particular, readers should first read and refer to the basic process flow as shown in the diagrams and discussion in these blog posts:

• FairPay Changes the "Game" of Commerce -- The algorithm decides whether to repeat the game at step 3 of the basic game cycle. 
• FairPay Pricing -- Some Process Diagrams – a more complex variation, with multiple tiers.
• Guiding FairPay Pricing for Control and Predictability -- further discussion on the basic strategies.

[This is largely as drafted 1/17/12, with minor corrections 10/17/18, and a number of explanatory comments added to the Level 1 discussion on 2/8/20 in response to developer questions.]

Please contact us at fairpay@teleshuttle.com for free assistance in understanding this outline and how it might be adapted to a particular business.

Those interested in implementing FairPay are encouraged to join the LinkedIn group “FairPay: Adaptively Win-Win Customer Relationships” to learn from and exchange information with others.

----

Recurring Subscription Sales

Two levels of features are outlined here – it is suggested that Level 2 be included or added soon after Level 1.  FairPay is a highly flexible architecture, and a wide range of variations and extensions are described elsewhere (see Further Notes, below).

Note that a much simpler variant of FairPay is outlined at the end, called Trial/Survey/Voluntary Mode. That variant nudges users toward fairness, but makes no attempt to enforce fairness with the threat of ending FairPay privileges (that significantly reduces complexity). In this mode it works as a voluntary patronship program with variable contributions and just soft nudging -- essentially an advanced form of crowdfunding.  

Discrete Item Sales and Trial/Survey Mode are also addressed in Further Notes.

Level 1 – Simple Feedback Cycles

This addresses user-set prices, with a probationary warm-up period for new buyers, and a very basic approach to FairPay reputation and offer criteria.

Request for Pricing

For each transaction cycle, Seller sends buyer a Request for Pricing after each use period: 

Seller includes a Suggested Price (SP) for the period, based on units of usage (or flat), with report of units used.  (This may be any suggested or reference price.)

Buyer is asked to respond with price setting:

·         Buyer Price (P) = absolute price and

·         Buyer Price Differential (PD) = ±% of suggested price

(The buyer may input either -- it is suggested to show both as a result.)

·         Note, Sellers may be given the option to not provide a Suggested Price to the Buyer.  In that case the SP would be used internally for the threshold computations below, and the PD would not be shown to the Buyer.

·         SPs may correspond to conventional set prices, but in general they may differ, and it may often be most effective to set them somewhat lower (for average usage), to add to the appeal of FairPay pricing, as a special privilege.

For example a buyer may be given a Suggested Price of $10, and the buyer may choose to pay $8 or -20%

Raw Transaction FP Reputation (Raw TFR, or RTFR)

Raw TFR = PD (±%)

In the example of $8 buyer price vs. suggested $10, the RTFR is -20%

Adjusted TFR (ATFR)

Level 2 adjusts TFR for Value Factor reasons stated by Buyer.  This is suggested as highly desirable, but not essential.

For Level 1, Adjusted TFR = Raw TFR

Multiple cycles

As the cycles repeat, the buyer passes through a probationary period, and a Cumulative FP Reputation is derived from the individual transaction ATFRs.  This is then used to control Offer Thresholds for future offers.

Cumulative FP Reputation (CFR) = exponentially smoothed ATFRs  (=average, weighted for recency)

The exponential smoothing factor is set by Seller (or set to a default value).

Offer thresholds

Offer Acceptance Function (OAF) is the function used to determine if offers are to be made: 

·         Offer if CFR > Threshold T (else send to standard set-price offers)

Seller sets Threshold Tn = minimum CFR to make FP offer

n=cycle number, starting with 0 at first offer to new buyer.

For New Buyers:

·         Warmup/Trial period for new Buyers = m cycles  (Seller sets m)

·         For Ongoing:  TN for limited Probation warning, and TNX for Reject/Strong Warning (for cycles after m)

·         New:  n cycles done, = Tn (T0, T1, …Tm)

·         Warn/probation if CFR

·         Reject/Strong warning if CFR

Example:  (exemplary, not necessarily recommended values):

TN = -30%,                 TNX = -50%

T0 = -100%,                T1 = -100%,                T2 = -60%,                  T3 = -40%

m = 3

This provides for 4 cycles of warm-up. The idea is to go through a number of trial cycles before cutting anyone off, so there are special, more relaxed thresholds for the first few cycles (m=3 in the example =  4 cycles of warm-up, 0-3). The example sets T0 = -100%, T1 = -100%, T2 = -60%, T3 = -40%, which override TNX to be more forgiving at those initial 4 stages.  After that, the standard TNX kicks in to trigger a rejection. So:

·         If the buyer paid -20% on each cycle they would not hit any probationary warnings. (A user paying -20% at all times is above all thresholds, so causes no warnings.)

·         If the buyer paid nothing (-100%) on each cycle, they would get limited Probation warning at T0 and T1, and get Reject/Strong Warning at T2, triggering Alert to Seller rejection handling, as below. (A user paying -100% is not < T0 or T1, but is < TN, so warnings given on the first 2 cycles; it is

·         If the buyer paid -50% on each cycle, they would get limited Probation warning at T0-T2, and get Reject/Strong Warning at T3, triggering Alert to Seller rejection handling, as below. (A user paying -50% is not < T0 or T1 or T2, but is < TN, so warnings given on the first 3 cycles; it is

·         At any time the buyer CFR dropped to less than -30% after the initial 4 cycles, they would get a limited Probation warning (based on TN), and at -50% they would get a Reject/Strong Warning (based on TNX), triggering Alert to Seller rejection handling, as below.

Rejection Handling and Overrides

Rejection handling is at seller discretion, handled by Seller processing in response to a Rejection Alert. Rather than doing a hard reject based on TNX, the seller can decide to trigger a manual review to decide whether to actually do a full hard reject, or to give stronger warnings and/or limited restrictions.  That might be desirable at least until there is confidence that the rejection process is not too harsh.

Such as Rejection Alert would provide information on CFR, TFRs, Thresholds, Cycles

Based on that Rejection Alert, Seller processing can determine whether to Reject, or to kick the Buyer into a Manual Review/Override process:

·         If Reject, then downgrade from FairPay and offer standard set-pricing (or drop entirely).

·         Manual Review/Override can trigger desired warnings and other actions, such as extending n more cycles, and possibly including manual adjustment of CFR.

·         For buyers previously rejected, an external process can also consider re-try of FP offers after a period of set-price use.

Other Override Processing by Seller could change CFRs or any other parameters for a given buyer.

Level 2 – Adds Buyer Explanations of Fairness

This adds consideration of buyer explanations by adjusting for reasons/justifications for prices (as only slightly more complex, but significantly more effective).

Value Factor questions/reasons (VF)

This provides a simple structure for Buyers to state reasons/justifications for a price above or below the suggested price, in a format usable for simple evaluation and adjustment of TFRs.

Responses can be coded as -2, -1, 0, +1, +2, with corresponding verbiage [alternatively, -5 to +5]

(eg: -2=Not at all, -1=somewhat, 0=OK, +1=more than OK, +2=very much)

Standard questions (Seller option to ask or not, and to vary wording):

1.      Quality: Did the quality of the results meet your needs/expectations

2.      Technical effectiveness:  Did the system work properly?

3.      Ease of use:  Was the system/service easy to use and understand

4.      Style (for content):  Were the style of the results to your taste?

5.      Value to you:  Did the results provide real value to you?

6.      Ability to pay:  Do you have average means to pay?
+Ask for reason?  (eg: retired, unemployed, student, affluent, business user, non-profit, startup, large business)

7.      Custom Seller value factor(s):  [Seller text]

Free Form Entry box - In addition, the service should enable entry of “any clarifying comments regarding the fairness of your price” (Seller option to include or not)

Adjusted TFRs (factoring in Value Factor reasons) (Optional)

Computation of adjustment:

Seller sets VF Weighting Factor (VFW), for each of above questions (fractional weights, adding up to 1)

At each transaction price setting, compute weighted average of VFs – Average VF (AVF)

Seller set Overall Value Factor Adjustment (OVFA) for adjustment of TFRs, CFRs:

Apply to Raw TFRs to get Adjusted TFRs, compute Adjusted CFRS and match ACFRs to Thresholds

·         OVFA for AVF = 0, adjust RTFR by 0

·         OVFA for AVF =-1, adjust RTFR by Seller set adjustment increment
      (eg: to allow for -30%, adjust raw TFR+30%pts – so a RTFR of -30% adjusts to an ATFR of 0)

·         OVFA for AVF = -2, adjust RTFR by Seller set adjustment increment
      (eg: to allow for -50%, adjust raw TFR+50%pts)

·         OVFA for AVF = +1, adjust RTFR by Seller set adjustment increment
      (eg: to allow for +30%, adjust raw TFR-30%pts)*

·         OVFA for AVF = +2, adjust RTFR by Seller set adjustment increment
      (eg: to allow for +100%, adjust raw TFR -100%pts)*

·         OVFA for intermediate values: Interpolate (linear interpolation or curve fit).

(*Consider applying a limiting factor for downward adjustment of high VFs associated with relatively low prices for such high VFs  that would otherwise lead to very unsatisfactory ATFRs for prices that are not otherwise unacceptable?)

Further Notes

1.  Discrete Item Sales (versus Subscription)

The above example addresses recurring subscription-based sales with a regular billing cycle.  FairPay applies very similarly to discrete item sales in an ongoing (but more irregular) relationship. 

·         Differences relate to the variable timing of discrete item purchases\ agreements and of the follow-up payment requests (which may follow after a set time and/or based on item usage events). 

·         Discrete items may be treated in individual item sales cycles or may batched into bundles of multiple items (based on number of items, value, etc., such as n songs or e-books or service items), with pricing, reputation evaluation, and offer gating processes batched at the bundle level. 

·         When done at the bundle level, pricing might be in aggregate for the bundle, or can be broken down to set individual item prices (such as for cases where item value may vary widely, and/or where revenue shares may go to different item providers, such as authors, artists, etc.).

2.  Trial/Survey/Voluntary Mode

An optional intermediate stage in phase-in of new FairPay services is to begin with a transitional Trial/Survey Mode.

·         This works much like a free trial, but with collection of Buyer pricing for informational use -- as market research and to aid in setting suggested prices.

·         It also includes modes that act as a pay what you want trial, but with payment in arrears (“pay as you exit”).  This “pay as you like, as you exit,” or Real-Payment Survey Mode, can be a useful pricing model in itself. (It collects CFR data, but does not use it to limit offers during the trial period.)

The second variant can nudge users toward fairness, but it makes no attempt to enforce fairness with the threat of ending FairPay privileges (that significantly reduces complexity). In this mode it works as a voluntary patronship program with variable contributions and just soft nudging -- essentially an advanced form of crowdfunding

This can be applied with a reduced-scope implementation, and is described at http://www.fairpayzone.com/2011/08/fairpay-free-trialsurvey-mode-easing.html.

3:  Additional Information

General background on FairPay is on the Web at http://www.fairpayzone.com/p/overview.html. Additional discussion of features and use cases is on the Web site and blog.