Planned changes

📘

SupplyAPi – new “receiveUpdates” method to receive updates

Applies to API and manual projects as well

requestStatus: in development
Receive from sample partners in the blend of a subsample, the status of the request (delivering the completes according to sample specs we expose via SupplyAPI methods), so it can be stored and displayed in an interface for Field coordinators (different user story for display)
Statuses we expect(configurable):

• not picked up
• processing
• sample sent
• sample stopped
• error

mode: automated/manual: planned
Send the mode of the request: automated if the project is run via API, or manual if a project manager is assigned on the supplier side.

supplierCPI: not planned
Receive the current CPI expected by supplier; needed to make sure Ipsos CPI is in line with the CPI set in the supplier platform. This would be used for internal alerts to make sure the correct CPI is set in the Ipsos platform

supplierConversion: not planned
Used for reporting/investigation purposes: whenever there is a CPI change, it would be interesting to understand if the conversion we see on the Ipsos side for a supplier matches the one stored on the supplier platform. not used for execution in any way.

forceCPI: not planned
Used in addition to maxCPI (see live-details enhancements), for fully automated jobs that require manual intervention on supplier side and potentially a higher CPI. Validations to be defined moving forward.

TBD other fileds

📘

live-details enhancements

expose maxCPI: not planned
For fully automated jobs that need manual intervention on supplier side, expose a maximum accepted CPI, so no email confirmation is needed.

expose feasibilityId: in development
Expose feasibilityId automatically generated by Feasibility to all sample vendors, so they can make the connection between pre-commissioning and execution stages in their systems
Is ok to be blank for subsamples / suppliers where feasibility was not run automatically via Feasibility API.
feasibilityId: id
Estimated live date: Q1 2020

expose auto increment quotas property: in testing
Expose properties defining auto-increment quotas to all sample partners, so they know in advance that additional completes will be expected during upcoming hours / days / weeks. Quota counts, field end will be automatically updated by this method and exposed via quotas / get-detailed as well
Why: structured way to increase quotas while in field (e.g. daily quotas for trackers)
Action expected: none, just awareness. Counts and end date for the project will adjust while in field, this property is just setting the expectation that this will happen

• How many completes (additional completed will be added to all quota cells according to their original distribution inside a quota table)
• How often(hourly, daily, etc)
• End date
  Estimated live date: February 2020

expose FC email address: live
Expose the email address of the field coordinator to all sample vendors, so they can make contact the user via email in case of an error.
primaryProjectManagerEmail: email_address

📘

SupplyAPI – new “fieldProgressAlerts” method as an alternative for email notifications

Trigger API calls to a partner endpoint related to field progress, so their system can automatically react to our alert. With emails we are forcing human intervention, something that we’d like to avoid.

On the partner side this could trigger an internal email, increased priority for that specific project, etc.

TBD from an implementation POV if a predefined list of alerts with an associated code would work, or if we can go more dynamic.
Ex1: fieldAlerts(supplier1, code112)
Ex2: fieldAlers(supplier1, trigger, fieldProgress, fieldCompletion, expectedFieldCompletion)

📘

SupplyAPI and expose deviation property (flex quota)

Expose the deviation property to all sample partners so they understand that total number of complete might not follow the quota cell distribution

• quota table level
• will change during field, toward the end

Why: controlled way to relax quotas toward the end of the field. If a specific combination of quota cells adds up to a difficult profile (eg 18-24, rich, rural area) adding a deviation to a quota table means that each quota cell in that table can will allow some flexibility (determined by the number of completes in the deviation property)
Action expected: potentially aim to go for easier to achieve cells when deviation is set and always look at total number of completes in a quota

Estimated live date: November 2019

Setting a custom deviation on the Gender quota

Deviation info in JSON

📘

SupplyAPI to expose survey restricted profiles

Expose in a dedicated quota table all profiles that are locked by the survey logic.

For example: a survey might need both males and females, both young and old. In the survey itself a client category (eg Nike users) might only need young males and as the survey progresses, that category won't need completes anymore. While the survey still accepts males and also young people, it won't receive young males anymore. In this scenario, the quotas method will expose a new quota table "SurveyRestrictedProfiles" with a quota cell males crossed with young age bracket with a needed count of 0. We're also considering using a new quota type "restrictive" to be super safe.

This change will likely trigger a new SAPI version: 1.1 to be used.

Why: improve conversion rates, target more accurately as the field progresses
Action expected: do not target restricted profiles

📘

SupplyAPI and expose locked property

Expose the locked property to all sample partners so they understand that the quota cells with locked=true property should not be targeted

• quota cell level
• will change during field, most likely started with locked and unlocking after

Why: controlled way to prioritize critical cells. If 18-24 is hard to reach, lock all other age brackets to make sure no 18-24 are screened out on other variables that might get filled fasters from other age brackets
Action expected: do not target cells with the locked property

📘

SupplyAPI expose field metrics after soft launch

Expose field metrics gathered in field after soft launch with Ipsos panel(when available), so supplier can send the right volume of traffic to cover the expected number of completes.

• softlaunchClientLOI
• softlaunchIncidenceRate

Why: accurate starting field metrics
Action expected: look at these indicators when available, instead of “estimated” before the initial launch

📘

SupplyAPI – new “projectTeam” method supplier team via API in Sample One

Allow sample partners to set their team project level (for each subsample) via API, so they are not forced to use supplier site to do this and receive supplier notifications.