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

WG

CLOSED

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.

24/APR: Agreed by the WG to merge baseline proposal. Follow Up in Issue#30. PR https://github.com/camaraproject/CustomerInsights/pull/29 MERGED and Issue is CLOSED.

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.

24/APR: DT is still pending to further check about this topic. DT comments another idea, if we consider scoring model as country specific, maybe indicate this scoring granularity based in some model in the response, but not sure if this would be needed.

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

TEF

NEW

24/APR: New issue opened by TEF on 24/APR. Within this issue the pending topics (sources and examples for algorithm model will be provided). Some initial input provided by TEF regarding sources provided, still some concepts to be checked. It is asked within the WG whether level of granularity/deep is fine (Telco Operator system that hosts this information) and WG (CT, VF) sees that approach OK. It will be needed more time to get some examples to show and document them. It is expected to generate inital PR in the next weeks, once the source is consolidated for them and communicated to the WG.

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

DT

NEW

24/APR: New issue opened by DT on 24/APR. It tries to manage the case in countries where there is personal identification number that changes when renewed but national identification number is kept from the first time it is generated (for instance this happens in Poland and it is a case in finantial procedures). It has also to discuss with Business Team. Some clarifications are commented by TEF, just to understand the topic. The “idDocument” concept refers to the national identification number that never changes (it is permanent) and in some countries the ID number of the document changes every time that document is renewed.
So probably some clarifications will have to be done regarding “idDcoument” and also being checked by DT whether ID number of the document is also needed as optional for Use Cases within the context of this API. DT also will add some reference to wikipedia for this concept.
VF comments about the use of idDocument/phoneNumber. In Spring25, in 3-legged scenario no identification needs to be provided as API susbject is identified by the token. Thery are needed for 2-legged scenario and depending on Telco Operator rules (some Operators may only need phoneNumber, others both to perform a double-check to ensure is the same API Subject).

API Release Tracker https://github.com/camaraproject/CustomerInsights/issues/32

WG

CLOSED

Issue created and API Release Tracker created after the meeting.

API Release created:

• https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/111706246/customer-insights+v0.2.0?atlOrigin=eyJpIjoiZTQ1NTViZjFiMmQzNDU0ZGE1MjQxYTM2YmE3MTg3MmUiLCJwIjoiYyJ9

AoB

WG