Cisco Service Control Online Advertising Solution Guide: Behavioral Profile Creation Using RDRs, Release 5.2.x

Cisco Service Control Solution Guide

Cisco Service Control Online Advertising Solution Guide: Behavioral Profile Creation Using RDRs, Release 5.2.x

Overview

Configuring Behavioral Targeting Support: Highlights

Configuring a Cisco SCE Platform for Exporting Behavioral Targeting Information

Anonymized HTTP Transaction Usage RDR

Hash Algorithm

Obtaining Documentation and Submitting a Service Request

Revised: September 23, 2015

---

Note This document supports all 5.2.x releases.

Overview

Online Behavioral Targeting is an online advertising approach that involves presenting users with advertisements based on their interests, as deduced by monitoring their web browsing preferences. The Cisco Service Control Engine (Cisco SCE) platform can enable online behavioral targeting based on an analysis of subscriber online usage patterns.

Such behavioral targeting does not require the analysis of each and every HTTP request on the line, because such analysis would result in numerous excess information. The Cisco SCE platform performs the first level of analysis in the behavioral targeting chain by inspecting the user browsing sessions, detecting the particular requests that are triggered by the actual user browsing (these events are termed ClickStream), and generating Raw Data Records (RDRs) that contain a digest of these events. To avoid compromising subscriber privacy, the RDRs can be configured to not include any Personally Identifiable Information (PII), in which case all elements containing PII are hashed. The RDRs are typically received by an entity that analyzes the nature of usage and creates a profile of the subscriber to be used later for targeting. The way the greater solution works is outside the scope of this document.

Figure 1 illustrates the high-level overview of an RDR-based behavioral targeting solution.

Figure 1 High Level Overview of an RDR-based Behavioral Targeting Solution

 

ClickStream detection is a fundamental capability of the solution, because it can detect which specific requests, out of the enormous number of HTTP requests generated throughout the subscriber web activity, were actually triggered by the subscriber browsing the web. When a subscriber clicks a link, or enters a URL in the browser address bar, an HTTP request is generated to fetch this URL. Typically, an HTML page is returned, which constitutes the outline of the contents requested. For the browser to be able to render this page, it must download multiple objects (tens or sometimes around a hundred for a single page viewed), which in turn results in multiple HTTP requests for obtaining these objects.

To carry out behavioral targeting, it is sufficient to understand what the user was trying to do (represented by the initial request, such as biz.publisher.com/ap/081120/world_markets.html > global markets), rather than looking at each object downloaded as a secondary result of such a request (such as: http://ads.adnetwork.com/a/a/in/interbroke/300x250_yah.jpg > broker advertisement).

ClickStream detection makes exactly this distinction, allowing the number of requests to be analyzed to be greatly reduced, which is necessary to enable a scalable analysis solution.

The information that is collected per such transaction is exported from the Cisco SCE using Extended Transaction Usage RDRs, which includes information on the transaction that has been performed, in addition to information on the subscriber that performed the transaction.

PII, such as subscriber ID and IP address, is protected by hashing this information with the use of preconfigured “salt”. In this way, the subscriber record can be matched only by another system configured with the same salt, in which case it has the original PII to match against. Salt is configurable to the Cisco SCE platform.

Configuring Behavioral Targeting Support: Highlights

This section provides the highlights of configuring the main components of behavioral targeting on the Cisco SCE platform. For configuration details, see the “Configuring a Cisco SCE Platform for Exporting Behavioral Targeting Information” section.

Configuring a Cisco SCE Platform for Exporting Behavioral Targeting Information

This section explains in detail how to configure an Cisco SCE to generate ClickStream RDRs.

---

Step 1 In the Cisco SCA BB Policy Editor, click the Classification tab (left pane), click Configuration, and select Protocols.

Step 2 In the Protocol Settings window (see Figure 5), select the HTTP Browsing service.

Step 3 On the Protocol Elements tab, remove the ClickStream-related protocol elements:

• In-Domain ClickStream
• In-Domain ClickStream - Unidirectional Client Request
• Cross-Domain ClickStream
• Cross-Domain ClickStream - Unidirectional Client Request

Figure 5 Protocol Settings

 

Step 4 In the Protocol Settings window, on the Protocols tab, click the Add (+) icon to add a new protocol.

Step 5 Enter a name for the new protocol ClickStream Event, and click OK (see Figure 6 ).

Figure 6 Protocol Settings—Name

 

Step 6 On the Protocol Elements tab, click the Add (+) icon to add protocol elements to the ClickStream Protocol.

Step 7 For the new protocol element created, click the “ … ” button in the Signature column.

Step 8 In the Select a Signature dialog box (see Figure 7), add the In-Domain Click Stream signature, and click OK.

Figure 7 Select a Signature

 

Step 9 Repeat Step 6 through Step 8 for the rest of the ClickStream signatures:

• In-Domain Click Stream - Unidirectional Client Request
• Cross-Domain Click Stream
• Cross-Domain Click Stream - Unidirectional Client Request

Step 10 In the Cisco SCA BB Policy Editor, click the Classification tab (left pane), and highlight the Browsing service.

Step 11 Click the Add (+) icon to add a new service under the Browsing service.

Step 12 Name the service ClickStream (or any other name you choose) (see Figure 8).

Figure 8 Service Settings

 

Step 13 Click the Hierarchy tab (see Figure 9) and check the two check boxes to add a dedicated service counter to the ClickStream Service. (This is useful if you want to generate reports on the global and per-subscriber ClickStream activity.)

Figure 9 Hierarchy

 

Step 14 Click OK.

Step 15 In the right pane, click the Add (+) icon to add a service element.

Step 16 In the dialog box that opens, click Select next to the Protocol field and select the ClickStream Event protocol (or whatever you named your ClickStream protocol) from the list (see Figure 10).

Step 17 Click OK.

Figure 10 Edit Service Element

 

Step 18 In the Cisco SCA BB Policy Editor, click the Policies tab (left pane), and then select the package for which to generate the ClickStream RDRs.

Step 19 In the right pane, click the Add (+) icon to add the ClickStream service.

Step 20 In the window that opens (see Figure 11), select ClickStream from the drop-down list.

Figure 11 Add New Rule to Package

 

Step 21 Click OK.

Step 22 In the Cisco SCA BB Policy Editor, repeat Step 18 through Step 21 for every package for which you want to enable ClickStream RDRs.

Step 23 In the right pane, click Configuration and choose Classification > RDR Settings.

Step 24 Click the Transaction Usage RDRs tab (see Figure 12).

Figure 12 RDR Settings—Transaction Usage RDRs

 

Step 25 Enable Extended TURs by checking the relevant check box.

Step 26 (Optional) Enable the anonymize option as needed, by checking Anonymize - Encrypt Personally Identifiable Information.

Step 27 Check the ClickStream service on all relevant packages, to enable generating RDRs for this service. Uncheck any other service for which you do not want Transaction Usage RDRs (extended or regular) generated.

---

Note Make sure that you have already created a specific rule for ClickStream on all relevant packages.

Step 28 Choose Policies > Configuration > System Settings (see Figure 13).

Figure 13 Service Configuration Editor—Policies > Configuration > System Settings

 

Step 29 On the Advanced Options tab, click Advanced Service Configuration Options (see Figure 14) to enable deep inspection of HTTP flows (beyond the first transaction) by setting the highlighted value to 64000. This enables the analysis of multiple transactions within a single HTTP flow, which is important for comprehensive detection of ClickStream events.

Figure 14 Advanced Service Configuration Options

 

Step 30 Apply the Service Configuration to the SCE platform.

Step 31 (Optional) If the anonymize option is enabled, configure MD5 salt to the SCE platform (use a 128-bit salt value of your choice) by using this command:

Step 32 Map the Extended TUR for HTTP (tag 0xF0F0F53C / 4042323260) to RDR category 2 by using this command:

Step 33 Direct category 2 to your server of choice by using this command:

Step 34 Save the configuration by using this command:

 

Anonymized HTTP Transaction Usage RDR

The RDR tag of the Anonymized HTTP Transaction Usage RDR is F0 F0 F5 3C / 4042323260.

Table 1 lists the RDR fields and their descriptions.

 

Further elaboration on RDR fields:

• HASHED_SUBSCRIBER_ID—Subscriber identification string, introduced through the subscriber management interfaces, passed through hashing algorithm as described in the “Hash Algorithm” section.

The field is a 32-byte-long string, containing a Hexadecimal notation of the 128-bit hash result.

• PACKAGE_ID—ID of the package assigned to the subscriber whose traffic is being reported. An assigned Package ID is an integer value between 0 and maximum_number_of_packages. The maximum_number_of_packages value is reserved for unknown subscribers.
• HASHED_SUBSCRBIER_IP—IP address of the subscriber side of the reported session, after passing through the hashing algorithm as described in the “Hash Algorithm” section.

The field is a 32-byte-long string, containing a hexadecimal notation of the 128-bit hash result.

• CLIENT_PORT—For TCP/UDP-based sessions, the port number of the client side (initiator) of the networking session. For non-TCP/UDP sessions, this field has the value 0.
• CONFIGURED_DURATION—For periodic RDRs, the configured period, in seconds, between successive RDRs.
• END_TIME—Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of January 1, 1970.
• FLAVOR_ID—For protocol signatures that have flavors, this field contains the ID of the flavor associated with this session.
• PROTOCOL_ID—Contains the unique ID of the protocol associated with the reported session.

---

Note The PROTOCOL_ID is the Generic IP, Generic TCP, or Generic UDP protocol ID value, according to the specific transport protocol of the transaction, unless a more specific protocol definition (such as a signature-based protocol or a port-based protocol), which matches the reported session, is assigned to a service.

• PROTOCOL_SIGNATURE—Contains the ID of the protocol signature associated with this session.
• REPORT_TIME—Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of January 1, 1970.
• SERVER_IP—Contains the destination IP address of the reported session. (The destination is defined as the server or the listener of the networking session.) The IP address is in a 32-bit binary format.
• SERVER_PORT—For TCP/UDP-based sessions, this field contains the destination port number of the networking session. For non-TCP/UDP sessions, this field contains the IP protocol number of the session flow.
• SERVICE_ID—Indicates the service classification of the reported session. For example, in the Transaction RDR, this field indicates which service was accessed, and in the Breaching RDR, this field indicates which service was breached.
• TIME_FRAME—System supports time-dependent policies, by using different rules for different time frames. This field indicates the time frame during which the RDR was generated. The value can be in the range from 0 to 3, indicating which of the four time frames was used.
• ZONE_ID—Contains the ID of the zone associated with this session.

---

Note All volumes in RDRs are reported in Layer 3 bytes.

Hash Algorithm

Hashing is done using the MD5 hash function, using a “salt” prepended to the hashed value.

• “salt” means adding a predefined value before the to-be hashed fields, to avoid simple backtracking of the source argument. The salt currently used by the SCE platform is 128 bits long and is configured to the SCE in four separate 4-byte arguments represented in HEX.
• Setting the salt is done through CLI using a hexadecimal notation. It can be updated periodically. (By default, it set to 0x12345678 0x12345678 0x12345678 0x12345678.)
• Hash result is 128 bits long, and is represented in RDRs as a 32-byte string. Each byte represents 4 bits of the result. To make it printable, add 64. (for example, 0000 mapped to ASCII(64) = '@'; 1111 mapped to ASCII(127) = '_').
• Short-hash that appears in RDRs is composed of the lower 32 bits of the hash result.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What’s New in Cisco Product Documentation at: http://www.cisco.com/c/en/us/td/docs/general/whatsnew/whatsnew.html.

Subscribe to What’s New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.