Profile

An entity corresponds to a uniquely identifiable attribute in the data model. E.g. Mobile Number for a Telecom Subscriber, Cell ID for a Cell Tower, customer Id for a banking customer etc. A collection of features related to the entity. Such collection may include Static features (e.g. DOB) + Historic Features (e.g. Revenue last month) + Semi Historic Features (e.g. Dropped calls let hour) + Last-Known Features (e.g. last known location, last topup amount, etc.). The Real-time Features come in the form of Real-time events.

Profiles are technically a collection of tables in Redis, each table has a key and value is a hash map. This hash map further has key value pair, representing the profile attribute name (like gender) as key and attribute value (like Female) as value.

Profile Configuration

Profile configurations are defined in etc/model/profiles directory. below is the example of a solution containing two profiles definition:

                        $ tree etc/model/profiles/
etc/model/profiles/
├── customer
│   └── profile.json
└── tower
    └── profile.json

                    

The name of profiles are Customer and Tower, the profile Customer represents telcom sunscribers and profile Tower represents cell tower installed by telecom providers.

The profile.json file is structures as below:

                        {keyAttribute": "MSISDN","masterTable":"CUSTOMER_PROFILE","name":"Customer","tables":[{"name":"CUSTOMER_PROFILE","type":"Dynamic"},{"name":"CUSTOMER_SEGMENT","type":"QuasiStatic"}]}
                    

The above definition of Customer profile is configured that the keyAttribute is MSISDN (Mobile number), This profile contains two tables i.e., CUSTOMER_PROFILE and CUSTOMER_SEGMENT. Among them the master profile is CUSTOMER_PROFILE. The profile is of two types. Dynamic types is table that can be changed any time in realtime and attribute values are very dynamic in nature like lastTransactionAmount. whereas a QuasiStatic table could changes slowly like customerSegment. The clients which accesses the profile will invalidate the cache based on type of the profile table. a Dynamic table will be accessed each time by discarding cache, whereas a QuasiStatic tables will keep the cache for 10 minutes.

Once the profile are defined in etc/model/profiles directory, we need to change the product's configuration to point to these profiles. The profiles are configured in drive.profiles section of product configuration etc/drive.json:

                        ...."drive":{"profiles":["Customer","Tower"],}...."masterProfile":"Customer",....
                    
Note: 
                        Directory structure and nameing of profile directory is very
                                important as Detect will use
                                this to navigate and access a particular profile configuration. The
                                profile Customer is kept under
                                    profiles/customer/profile.json , if the profile name was
                                    Event Catelog then the directory stucture will
                                be profiles/event_catelog/profile.json.
We can have as many profiles as required by a solution but there
                                will one profile which is called master profile. This master profile
                                is used as a central entity profile and used as default profile for
                                audience and trigger evaluation.

                    