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

WG

CLOSED

07/FEB: All issues are closed. M3 reached: https://github.com/camaraproject/CustomerInsights/pull/21 is MERGED. API Readiness checklist has been updated customer-insights v0.1.1Preview.

20/FEB: Next step is to prepare Public Release actions. For that reason parent issue is opened. New sub-issues will be opened. Deadline for Public release PR is 28th February.

06/MAR: PR for Public Release delivered https://github.com/camaraproject/CustomerInsights/pull/24. Under RM review, also commented that internally the WG can review. Approved by the WG after the meeting.

20/MAR: Public Release Generated on 10th March. CLOSED ISSUE

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.

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.

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

TEF

CLOSED

20/MAR: New issue to align changelog. Changelog already fix manually in release notes. Addressed by PR https://github.com/camaraproject/CustomerInsights/pull/26

Approved and Merged after the meeting

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

WG

CLOSED

20/MAR: Typo in Error Exception example found. Addressed by PR https://github.com/camaraproject/CustomerInsights/pull/28 (New Public Release as a patch of the previous one)

Approved and merged after the meeting. Public Release r1.3 generated. API Release Traccker updated: customer-insights v0.1.1Preview

AoB

WG