Overview

The Visscore service allows for realtime prediction of incoming hits using .H5 Keras models.

Once loaded into the account, these models are fed data that has been inserted into our DB belonging to the visit being processed. This product level data us used to produce a propensity score.

Each Visscore box acts as a subscriber for 1 account (as defined in it's config.yml file) - see below, and will only talk to its specific SQS Queue,

SQS Design

During account creation we generate an SQS queue following this naming convention: visscore_<queue_type>_<account_token>. The param queue_type can be "main" or "retry" and the account_token will be the account token found in attrib_account.

Note

The "retry" queue is currently on the DPS/visscore boxes. The idea being once we've pulled from Amazon's SQS if we have failed to insert, we should just try again with the RetryWorkers - similar to our other systems - and thus not waste time/money sending the visit back to the SQS.

Account Ownership

The Visscore system works at the account level. On system init() it will read its own config.yml and find the account_token it should use.

Finding the account

DPS applications that serve only one account work by using the BaseSingleAccountList class.

BaseSingleAccountList.get_account()

This function simply returns self.server.config['account_token'] which is defined within Positive Internet's infrastructure.

BaseSingleAccountList.update_accounts()

This overridden version of AccountList.update_accounts() uses the account token that BaseSingleAccountList.get_account() returns to query attrib.attrib_account and set the account object in a similar way to any other D(C/P)S system.