Consumer management

OpenTV Platform supports a range of consumer management models:

• External CRM-driven consumer management An external CRM, signup and purchasing process is used to provision accounts for OpenTV Platform.

• Local accounts and external billing OpenTV Platform holds the user account and authentication data. Purchasing is performed using a pre-integrated billing platform.

• Hybrid An external CRM is used to provide the initial account and the OpenTV Platform processes transactional purchases, informing the CRM of the purchase.

Accounts & Profiles Model

In all cases, OpenTV Platform retains an account record for the consumer with several profiles. Each account has associated with it:

• Username/password (optionally can be linked to an external SSO)

• User details (name, address, etc.)

• Entitlements:

  • Transactional

  • Subscription

  • Capability

• PINs (as many as required by the user experience)

• NPVR

• Devices, with limits on approved devices and concurrent use (see Devices below)

• User profiles (at least one by default)

  • Parental controls

  • Viewing history

  • Favorites

  • Recommendations

  • Parameters (Key-Value-Pairs) used for additional data

  • Targeting Segments

  • Template home page (to allow 'childrens section')

Consumer access levels

The operator can offer the service at three levels. Each level unlocks more of the experience.

In anonymous mode:

• The app gets a limited-access guest session, so the consumer can start browsing straight away.

• The operator targets the menu and rails for guest users with Rails Builder segment targeting, for example to a "free" product.

• Sign-in and sign-up prompts appear:

  • in the main menu, or as a promotional banner;

  • when the consumer tries a locked feature;

  • at the end of free playback.

• The sign-up prompt shows a QR code to the operator's own sign-up page. Sign-up stays in the operator's systems.

nPVR can also be switched on or off for each consumer, based on the account's nPVR status. This lets an operator remove recording from consumers who downgrade.

Recommended Parental Control Behaviour

The user experience can customize the parental control logic through use of additional PINs and custom logic. NAGRAVISION recommends the following model:

• The consumer is offered the choice to set up a parental control PIN

• When set, this PIN controls:

  • Switching of profile

  • Creation of profiles

  • Setting parental controls on profiles

  • For profiles without a maximum age set, they can see all content. Content above a globally configured age rating (e.g. 15, 18 etc) will require the parental control PIN to play back

• The parental controls on each profile specify:

  • The maximum age of content that can be seen in the user experience

    • Rails, Search, EPG are filtered by the set parental control rating

    • Users can't 'see' the content, and are not able to request to play it again if they have already

Server-side PIN enforcement

By default, the client application checks the PIN before it calls the platform. The operator can also choose to have OpenTV Platform enforce the PIN itself. The platform then rejects the request if the correct PIN is not supplied, even if a client skips the check.

• Protected actions include:

  • switching from a child profile to a non-child profile (parental PIN);

  • purchasing (purchase PIN).

• Configured per action. The operator chooses which actions are protected and which PIN type applies to each. For example, one operator can use the parental PIN for everything, while another uses a separate purchase PIN.

• Phased roll-out. Enforcement uses new versions of the protected APIs. Existing client applications keep working unchanged, and each device type can move to enforced PINs when its app is upgraded.

• Off by default. It is switched on per deployment.

Devices

Approved-device limits per device group

Operators can limit how many devices an account can use for playback (approved devices), and how often the consumer can change the approved list.

• Limits per device group. Limits can be set for each group of devices, for example 2 big-screen devices and 4 mobile devices. Each group has its own count, so a new mobile device can never use a big-screen slot.

• Sell extra devices. Limits come from the account's device profile. To give a consumer more devices, for example after they buy a "3 big screens" product, the operator assigns a profile with a higher limit. The operator can also reset the change counter, so the consumer can approve new devices immediately after an upgrade.

• Lowering a limit does not remove devices that are already approved; it only applies to new approvals.

• Open devices only. Limits apply to open devices such as phones, tablets, browsers and retail TVs, not to operator-managed set-top boxes.

• Management. Limits and approved devices can be managed in Operator Console or through the API, for example from a CRM. Consumers can see and manage their approved devices in the app.

• Approved-device limits are switched on per deployment.

Location concurrency limits

Operators can limit where an account is watched from at the same time. A location is identified by the public IP address of the device.

• Maximum concurrent locations per account: for example, an account can stream from at most 2 locations at once.

• Maximum concurrent streams per location: for example, at most 3 streams from any one location.

Locations are counted automatically as streams start and stop; the consumer does not need to register them. Limits are set per account profile, so different consumer groups can have different rules. Location limits are enforced by NAGRA session management (SSM). They can be combined with stream limits per device group.

Minimum client version

Operators can make sure consumers use an up-to-date app.

• Two versions per device profile:

  • a warning version: at or below this version, the consumer is signed in and the app asks them to upgrade;

  • a block version: at or below this version, sign-in is refused until the app is upgraded.

• When it is checked. The check runs at sign-on and at every token refresh, so consumers who are already signed in are also caught.

• Missing version. The operator can choose to block clients that do not report an app version.

• Configuration. Version checks are set in Operator Console and are off by default. The app name and version reported by each device are also recorded against the device.

Self-care integration

OpenTV ION can link the consumer to the operator's own self-care portal, so account and billing tasks stay in the operator's systems.

• Entry points:

  • Settings or main menu: a link to the self-care portal.

  • Purchase failure: if a purchase is refused by the operator's payment system (for example, not enough wallet credit), ION shows a message with a link to the portal, so the consumer can top up and try again from the media card.

• How the portal opens:

  • inside the app, in a private web view, on devices that support it;

  • as a QR code and a short URL that the consumer opens on their phone.

  • The default (web view or system browser) can be configured per device.

• Automatic sign-in (SSO). ION passes the consumer's identity token to the portal, either in the URL or in a configurable request header. The portal validates the token with OpenTV Platform, so the consumer does not need to sign in again. When the token expires, the portal tells ION, and ION reloads the portal with a fresh token.

• Upsell context. When the link is opened from an upsell or purchase journey, ION also passes the context, for example the content or pack the consumer wanted. The portal can then take the consumer straight to the right offer.

• Configuration. The portal URL and the token method are set in the ION platform configuration.

For integration details, see the Self-care portal integration guide (IONDOC).