https://github.com/camaraproject/CustomerInsights/issues/22

WG

ONGOING

20/FEB: Initial approach for discussion is presented. Basically from TEF side checking with Brazil Operator. Only refer to concepts as algorithm details are protected by property rights. Waiting from feedback on which information could be shared.

Some questions and doubts are commented by VF. Regading social networks porbably in some VF markets that information would not possible to be provided due to legal reasons. TEF will check internally.

From DT side it is also commented a possible approach (it will be compiled more feedback) where an external Platform/3rd Party performs/implement the analytics behind a common algorithm within a given market. That would imply such external platform to have access to Telco Operator' information. TEF indicates it will comment this approach internally.

It is also commented that probably the algorithm model could vary from market to market. So initial purpose would be to have an MVP for initial values to be considered.

06/MAR: Some conversation around the issue https://github.com/camaraproject/CustomerInsights/issues/22#issuecomment-2671805466, regarding the initial comment generated by Kevin. Some points are provided feedback, other points are still being checked by Pedro.

About Rafal’s comment “The suggested approach from business team is to define the extended set of parameters and document it (for example in Additional Documentation folder) so we can have the common understanding what is behind each parameter name.
Then the scoring model can be agreed by operators on given market, taking into account market specifities and needs/requirements of customers of scoring API.”, the WG considers it is a good proposal/approach so as in the way initial set of parameters are agreed they can be documented.

There are also comments about the period to consider to some concepts, that can be discussed further even to define the same concept with a different periodicity.

Intention is once some clarifications are provided by TEF to agree in a initial list and move forward documenting a way like the proposal by DT.

20/MAR: Initial PR https://github.com/camaraproject/CustomerInsights/pull/29 generated.

Specific points commented:

• geographical_numbering_are concept

• align expected behaviour for those concepts that may be misleading in the understanding

• social_networks_data_consumption: may have gdpr constrains in a given market. Would be great if we can measure/indicate more important aspects to be considered for the algorithm

Kevin, Rafal and Pedro will have specific meeting to talk with more detail about this topic.

03/APR:
Specific meeting made offline. After it, considerations are:

• Initial approach is seen fine. Some enhancements are proposed.

  • Kevin: Provide examples about how different values could impact in scoring. Just to have a reference for the understaing as thresholds may vary market to market

  • Rafal: Provide information about the source of the concepts (e.g. customer_since_months matches kyc-tenure rationale)

PR https://github.com/camaraproject/CustomerInsights/pull/29 with initial approach is triggered. It will be reviewed (typos, wording) and it be merged. Further enhancements agreed will be accomplished in latter PR.

Question about “average_recharge_amount_in_{period}” commented. It refers to Top-Ups (for Prepaid subscriptions). Additional clarifications will be provided in the latter PR.

https://github.com/camaraproject/CustomerInsights/issues/23

DT

ONGOING

06/MAR: New Topic: Two levels of scoring precision in API.

DT brings this topic. Based on Czech republic business, there is two different levels of precision for the score (rough and detailed) with different prices, they have customer for both models. That is the business idea. And look for a technical solution for it.

TEF will check about this concept internally from business view. Also VF will talk internally about this concept.

20/MAR: TEF comments that business is aligned with the concept/idea of having different precision models in order to be able to monetize them with different API pricing. They do not see this concept as linked directly to a score model but to indicate different level of precision available for any scoring model, like a new input parameter that reflects the precision required. DT will share this internally to also get some feedback, also check how this is done in other WGs like device location, having different precision for the location of the device.

03/APR: Rafal will get information from Business side. As a comment a parameter could be accomodated in request to indicate the precision and if not indicated default precision is provided. Anyway, it is an observation and it is needed more details from Business before thinking in a technical solution. Also to check info from Operate APIs and TMF regarding the provision of a product and relationship to request a higher precision.

AoB

WG

Next Meetings:

• 17th April Meeting will be shifted by 24th April

• 1st May meeting will be cancelled

@pedro.diezgarcia@telefonica.com to manage this with LFX