A/B TESTING ON DEMAND

A machine may be configured to generate A/B test reports on demand. For example, the machine causes a display of a user interface for receiving a request of a customized report of result data of an A/B test. The machine receives, via the user interface, an identifier of the A/B test, a specification of a metric associated with the result data, a specification of a dimension of the metric, a specification of a location of the result data, and a request to generate the customized report. The machine generates the metric based on the identifier of the A/B test, the specification of the metric, and the result data. The machine generates the customized report pertaining to the dimension of the metric based on the generated metric and the specification of the dimension of the metric. The machine causes a display of the customized report in the user interface.

TECHNICAL FIELD

The present application relates generally to data processing systems and, in one specific example, to techniques for generating A/B experiments and A/B test reports on demand.

BACKGROUND

The practice of A/B experimentation, also known as “A/B testing” or “split testing,” is a practice for making improvements to webpages and other online content. A/B experimentation typically involves preparing two versions (also known as variants, or treatments) of a piece of online content, such as a webpage, a landing page, an online advertisement, etc., and providing them to separate audiences to determine which variant performs better.

DETAILED DESCRIPTION

Example methods and systems for generating AB test reports on demand are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that the embodiments of the present disclosure may be practiced without these specific details.

According to various example embodiments, an on-demand A/B testing and reporting system (also referred to hereinafter as “an on-demand A/B reporting system,” or “an A/B reporting system”) enables an experiment administrator or owner to conduct an on-demand A/B experiment of online content among users of an online social networking service (also “SNS”) such as LinkedIn®, and to generate a report based on the test result data of the A/B experiment. The A/B reporting system may also facilitate a customization of an existing A/B test such that the experiment administrator has more control over the A/B test and can request on-demand A/B test reports. An A/B reporting system that facilitates customization of A/B testing and reporting may include functionalities for providing the experiment administrator with options to select from existing metrics or to define a new metric, to select from existing metric dimensions (or fields) or to define new metric dimensions, to select a pre-existing assignment of users targeted by the A/B test or to define a new assignment of the target users to different variants of the A/B test, to select or to specify a preferred time period for which A/B tests should run or A/B test reports should be generated, etc.

An on-demand A/B reporting system that executes A/B tests that are customized on-demand and generates on-demand A/B test reports (hereinafter also “A/B reports”) provides an increased level of flexibility in A/B experimentation related to publishing of online content, operation of computer systems and database systems providing the online content, and operation of the network systems that facilitate the traffic to and from the systems providing the online content. Further, the on-demand A/B reporting system also provides the benefit of timely, on-demand execution of A/B tests or generation of A/B test reports that may be customized to particular (e.g., urgent) situations. Such on-demand A/B testing or reporting may be helpful in fast identification of system errors and, therefore, in providing more stable and robust computer, database, and network systems that facilitate generating, publishing, hosting, or accessing of online content.

In some example embodiments, an A/B reporting system causes a display of a user interface for receiving a request of a customized report of result data of an A/B test of online content. The user interface is caused to display on a client device associated with a user (e.g., a user of the SNS). The result data of the A/B test may be generated based on an execution of the A/B test by an A/B test system (e.g., the A/B reporting system). The A/B reporting system receives, via one or more input elements of the user interface displayed on the client device, an identifier of the A/B test, an identifier (e.g., a name or a specification) of a metric associated with the result data of the A/B test, an identifier (e.g., a name or a specification) of a dimension of the metric, an identifier (e.g., a name, a specification, or an address) of a location of the result data of the A/B test in a database associated with the A/B test system, and a request to generate the customized report. The dimension of the metric may be a data field of the metric. The A/B reporting system may also receive, via one or more input elements of the user interface, a specification of a time (e.g., a time range) for which to generate the customized report. The A/B reporting system accesses the result data of the A/B test from the database associated with the A/B test system based on the specification of the location of the result data. The A/B reporting system generates, using one or more hardware processors, the metric based on the identifier of the A/B test, the identifier of the metric, and the result data of the A/B test. The A/B reporting system, based on (e.g., in response to) the request to generate the customized report, generates the customized report pertaining to the dimension of the metric on demand based on the generated metric and the identifier of the dimension of the metric. The A/B reporting system causes a display of the customized report in an output element of the user interface of the client device associated with the user.

In some example embodiments, if a desired metric does not exist, a user of the A/B reporting system may provide a script for generating (e.g., calculating) the metric by the A/B reporting system. The user may provide the script by identifying a location of the script via the one or more input elements of the user interface displayed on the client device. The A/B reporting system may execute the script, and may assign the resulting value to the metric.

According to various examples embodiments, the A/B reporting system receives, via the one or more input elements of the user interface displayed on the client device, a specification of an assignment of one or more members of a social networking service (SNS) to one or more variants of the A/B test, and a request to execute the A/B test based on the specification of the assignment. The A/B reporting system, in response to the request to execute the A/B test, executes the A/B test based on the specification of the assignment. The executing of the A/B test results in a generation of the result data of the A/B test.

According to various example embodiments, to run an experiment, the A/B reporting system allows a user to create a testKey, which is a unique identifier that represents the concept or the feature to be tested. The A/B reporting system then creates an actual experiment as an instantiation of the testKey, and there may be multiple experiments associated with a testKey. Such hierarchical structure makes it easy to manage experiments at various stages of the testing process. For example, suppose the user wants to investigate the benefits of adding a background image. The user may begin by diverting only 1% of US users to the treatment, then increasing the allocation to 50% and eventually expanding to users outside of the US market. Even though the feature being tested remains the same throughout the ramping process, it requires different experiment instances as the traffic allocations and targeting changes. In other words, an experiment acts as a realization of the testKey, and only one experiment per testKey can be active at a time.

Every experiment is comprised of one or more segments, with each segment identifying a subpopulation to experiment on. For example, a user may set up an experiment with a “whitelist” segment containing only the team members developing the product, an “internal” segment consisting of all company employees and additional segments targeting external users. Because each segment defines its own traffic allocation, the treatment can be ramped to 100% in the whitelist segment, while still running at 1% in the external segments. Note that segment ordering matters because members are only considered as part of the first eligible segment. After the experimenters input their design through an intuitive User Interface, all the information is then concisely stored by the A/B reporting system in a DSL (Domain Specific Language). For example, the line below indicates a single segment experiment targeting English-speaking users in the US where 10% of them are in the treatment variant while the rest in control.

In some embodiments, the A/B reporting system may log data every time a treatment for an experiment is called, and not simply for every request to a webpage on which the treatment might be displayed. This not only reduces the logs footprint, but also enables the A/B reporting system to perform triggered analysis, where only users who were actually impacted by the experiment are included in the A/B test analysis. For example, LinkedIn.com could have 20 million daily users, but only 2 million of them visited the “jobs” page where the experiment is actually on, and even fewer viewed the portion of the “jobs” page where the experiment treatment is located. Without such trigger information, it is difficult to isolate the real impact of the experiment from the noise, especially for experiments with low trigger rates.

Conventional A/B testing reports may not accurately represent the global lift that will occur when the winning treatment is ramped to 100% of the targeted segment (holding everything else constant). The reason is two-fold. Firstly, most experiments only target a subset of the entire user population (e.g., US users using an English language interface, as specified by the command “interface-locale=en_US”). Secondly, most experiments only trigger for a subset of their targeted population (e.g., members who actually visit a profile page where an experiment resides). In other words, triggered analysis only provides evaluation of the local impact, not the global impact of an experiment.

According to various example embodiments, the A/B reporting system is configured to compute a Site-wide Impact value, defined as the percentage delta between two scenarios or “parallel universes”: one with treatment applied to only targeted users and control to the rest, the other with control applied to all. Put another way, the site-wide impact is the x % delta if a treatment is ramped to 100% of its targeting segment. With site-wide impact provided for all experiments, users are able to compare results across experiments regardless of their targeting and triggering conditions. Moreover, Site-wide Impact from multiple segments of the same experiment can be added up to give an assessment of the total impact.

For most metrics that are additive across days, the A/B reporting system may simply keep a daily counter of the global total and add them up for any arbitrary date range. However, there are metrics, such as the number of unique visitors, which are not additive across days. Instead of computing the global total for all date ranges that the A/B reporting system generates reports for, the A/B reporting system estimates them based on the daily totals, saving more than 99% of the computation cost without sacrificing a great deal of accuracy.

In some embodiments, the average number of clicks is utilized as an example metric to show how the A/B reporting system computes Site-wide Impact. Let Xt, Xc, Xsegand Xglobaldenote the total number of clicks in the treatment group, the control group, the whole segment (including the treatment, the control and potentially other variants) and globally across the site, respectively. Similarly, let nt, nc, nsegand nglobaldenote the sample sizes for each of the four groups mentioned above.

The total number of clicks in the treatment (control) universe can be estimated as:

Then the Site-wide Impact is computed as

which indicates that the Site-wide Impact is essentially the local impact Δ scaled by a factor of α. For metrics such as average number of clicks, Xglobal for any arbitrary date range can be computed by summing over clicks from corresponding single days. However, for metrics such as average number of unique visitors, de-duplication is necessary across days. To avoid having to compute α for all date ranges that the A/B reporting system generate reports for, the A/B reporting system estimates cross-day α by averaging the single-day α's. Another group of metrics include a ratio of two metrics. One example is Click-Through-Rate, which equals Clicks over Impressions. The derivation of Site-wide Impact for ratio metrics is similar, with the sample size replaced by the denominator metric.

FIG. 1is a block diagram illustrating various components or functional modules of a social network service such as the social network system120, consistent with some embodiments. As shown inFIG. 1, the front end consists of a user interface module (e.g., a web server)122, which receives requests from various client computing devices including one or more client device(s)150, and communicates appropriate responses to the requesting client devices. For example, the user interface module(s)122may receive requests in the form of Hypertext Transport Protocol (HTTP) requests, or other web-based, application programming interface (API) requests. The client device(s)150may be executing conventional web browser applications and/or applications (also referred to as “apps”) that have been developed for a specific platform to include any of a wide variety of mobile computing devices and mobile-specific operating systems (e.g., iOS™, Android™, Windows® Phone).

For example, client device(s)150may be executing client application(s)152. The client application(s)152may provide functionality to present information to the user and communicate via the network140to exchange information with the social network system120. Each of the client devices150may comprise a computing device that includes at least a display and communication capabilities with the network140to access the social network system120. The client devices150may comprise, but are not limited to, remote devices, work stations, computers, general purpose computers, Internet appliances, hand-held devices, wireless devices, portable devices, wearable computers, cellular or mobile phones, personal digital assistants (PDAs), smart phones, smart watches, tablets, ultrabooks, netbooks, laptops, desktops, multi-processor systems, microprocessor-based or programmable consumer electronics, game consoles, set-top boxes, network PCs, mini-computers, and the like. One or more users160may be a person, a machine, or other means of interacting with the client device(s)150. The user(s)160may interact with the social network system120via the client device(s)150. The user(s)160may not be part of the networked environment, but may be associated with client device(s)150.

The application logic layer includes various application server modules124, which, in conjunction with the user interface module(s)122, generates various user interfaces (e.g., web pages) with data retrieved from various data sources in the data layer. With some embodiments, individual application server modules124are used to implement the functionality associated with various services and features of the social network service. For instance, the ability of an organization to establish a presence in the social graph of the social network service, including the ability to establish a customized web page on behalf of an organization, and to publish messages or status updates on behalf of an organization, may be services implemented in independent application server modules124. Similarly, a variety of other applications or services that are made available to members of the social network service will be embodied in their own application server modules124.

As shown inFIG. 1, the data layer includes several databases, such as a database128for storing profile data, including both member profile data as well as profile data for various organizations. Consistent with some embodiments, when a person initially registers to become a member of the social network service, the person will be prompted to provide some personal information, such as his or her name, age (e.g., birthdate), gender, interests, contact information, hometown, address, the names of the member's spouse and/or family members, educational background (e.g., schools, majors, matriculation and/or graduation dates, etc.), employment history, skills, professional organizations, and so on. This information is stored, for example, in the database with reference number128. Similarly, when a representative of an organization initially registers the organization with the social network service, the representative may be prompted to provide certain information about the organization. This information may be stored, for example, in the database with reference number128, or another database. With some embodiments, the profile data may be processed (e.g., in the background or offline) to generate various derived profile data. For example, if a member has provided information about various job titles the member has held with the same company or different companies, and for how long, this information can be used to infer or derive a member profile attribute indicating the member's overall seniority level, or seniority level within a particular company. With some embodiments, importing or otherwise accessing data from one or more externally hosted data sources may enhance profile data for both members and organizations. For instance, with companies in particular, financial data may be imported from one or more external data sources, and made part of a company's profile.

Once registered, a member may invite other members, or be invited by other members, to connect via the social network service. A “connection” may require a bi-lateral agreement by the members, such that both members acknowledge the establishment of the connection. Similarly, with some embodiments, a member may elect to “follow” another member. In contrast to establishing a connection, the concept of “following” another member typically is a unilateral operation, and at least with some embodiments, does not require acknowledgement or approval by the member that is being followed. When one member follows another, the member who is following may receive status updates or other messages published by the member being followed, or relating to various activities undertaken by the member being followed. Similarly, when a member follows an organization, the member becomes eligible to receive messages or status updates published on behalf of the organization. For instance, messages or status updates published on behalf of an organization that a member is following will appear in the member's personalized data feed or content stream. In any case, the various associations and relationships that the members establish with other members, or with other entities and objects, are stored and maintained within the social graph database, shown inFIG. 1with reference number130.

The social network service may provide a broad range of other applications and services that allow members the opportunity to share and receive information, often customized to the interests of the member. For example, with some embodiments, the social network service may include a photo sharing application that allows members to upload and share photos with other members. With some embodiments, members may be able to self-organize into groups, or interest groups, organized around a subject matter or topic of interest. With some embodiments, the social network service may host various job listings providing details of job openings with various organizations.

As members interact with the various applications, services and content made available via the social network service, the members' behavior (e.g., content viewed, links or member-interest buttons selected, etc.) may be monitored or tracked, and information concerning the member's activities and behavior may be stored, for example, as indicated inFIG. 1in the database with reference number132.

With some embodiments, the social network system120includes what is generally referred to herein as an A/B reporting system300. The A/B reporting system300is described in more detail below in conjunction withFIG. 3.

Additionally, a third-party application(s)148, executing on a third-party server(s)146, is shown as being communicatively coupled to the social network system120and the client device(s)150. The third-party server(s)146may support one or more features or functions on a web site hosted by the third party.

Although not shown, with some embodiments, the social network system120provides an application programming interface (API) module via which third-party applications148can access various services and data provided by the social network service. For example, using an API, a third-party application148may provide a user interface and logic that enables an authorized representative of an organization to publish messages from a third-party application148to a content hosting platform of the social network service that facilitates presentation of activity or content streams maintained and presented by the social network service. Such third-party applications148may be browser-based applications, or may be operating system-specific. In particular, some third-party applications148may reside and execute on one or more mobile devices (e.g., phone, or tablet computing devices) having a mobile operating system.

Further, as shown inFIG. 1, a data processing module134may be used with a variety of applications, services, and features of the social network system120. The data processing module134may periodically access one or more of the databases128,130,132,136,138, or140, process (e.g., execute batch process jobs to analyze or mine) profile data, social graph data, member activity and behavior data, A/B test result data, metric data, or cohort data, and generate analysis results based on the analysis of the respective data. The data processing module134may operate offline. According to some example embodiments, the data processing module134operates as part of the social network system120. Consistent with other example embodiments, the data processing module134operates in a separate system external to the social network system120. In some example embodiments, the data processing module134may include multiple servers of a large-scale distributed storage and processing framework, such as Hadoop servers, for processing large data sets. The data processing module134may process data in real time, according to a schedule, automatically, or on demand.

According to various example embodiments, an A/B experimentation system, such as A/B reporting system300, is configured to enable a user of the A/B reporting system300to prepare and conduct an A/B experiment of online content among users (e.g., actual members or potential members/guests) of an online social networking service (also “SNS”) such as LinkedIn®. The A/B experimentation system may display a targeting user interface allowing the user to specify targeting criteria statements that reference members of an online social networking service based on their member attributes (e.g., their member profile attributes displayed on their member profile page, or other member attributes that may be maintained by an online social networking service that may not be displayed on member profile pages). In some embodiments, the member attribute is any of location, role, industry, language, current job, employer, experience, skills, education, school, endorsements of skills, seniority level, company size, connections, connection count, account level, name, username, social media handle, email address, phone number, fax number, resume information, title, activities, group membership, images, photos, preferences, news, status, links or URLs on a profile page, and so forth. For example, the user can enter targeting criteria such as “role is sales”, “industry is technology”, “connection count >500”, “account is premium”, and so on, and the system will identify a targeted segment of members of an online social network service satisfying all of these criteria. The system can then target all of these users in the targeted segment for online A/B experimentation.

Once the segment of users to be targeted has been defined, the system allows the user to define different variants for the experiment, such as by uploading files, images, HTML code, webpages, data, etc., associated with each variant and providing a name for each variant. One of the variants may correspond to an existing feature or variant, also referred to as a “control” variant, while the other may correspond to a new feature being tested, also referred to as a “treatment”. For example, if the A/B experiment is testing a user response (e.g., click through rate or CTR) for a button on a homepage of an online social networking service, the different variants may correspond to different types of buttons such as a blue circle button, a blue square button with rounded corners, and so on. Thus, the user may upload an image file of the appropriate buttons and/or code (e.g., HTML code) associated with different versions of the webpage containing the different variants.

Thereafter, the system may display a user interface allowing the user to allocate different variants to different percentages of the targeted segment of users. For example, the user may allocate variant A to 10% of the targeted segment of members, variant B to 20% of the targeted segment of members, and a control variant to the remaining 70% of the targeted segment of members, via an intuitive and easy to use user interface. The user may also change the allocation criteria by, for example, modifying the aforementioned percentages and variants. Moreover, the user may instruct the system to execute the A/B experiment, and the system will identify the appropriate percentages of the targeted segment of members and expose them to the appropriate variants.

In some example embodiments, the A/B reporting system300facilitates a customization of an A/B test and/or of reports generated based on result data of an A/B test. The A/B reporting system300may cause the display of a user interface for customization of a request to execute an A/B test on demand, or for customization of a request to generate an A/B test report on demand. The user interface may be caused to display on a client device150that is associated with a user160(e.g., an actual or potential member) of the SNS. The user interface may include a number of input elements (e.g., fields, drop-down menus, buttons, etc.) to receive input, by the user160, to be used in the customization of an A/B test or of an A/B test report. Based on receiving the input and a request to execute the A/B test on demand (or a request to generate an on-demand, customized A/B test report) provided by the user160via the user interface displayed on the client device150, the A/B reporting system300executes the A/B test on-demand (or generates the on-demand, customized A/B test report). The A/B reporting system300may cause a display of the on-demand, customized A/B test report in an output element of the user interface of the client device150associated with the user160.

FIG. 2illustrates a functional diagram of an example system, according to various embodiments. A user160of the SNS may interact, via client device202, with online content provided by the SNS. The social networking system120may track the member interactions204with the SNS, and may store data about the member interactions204in a record of the member activity and behavior database132.

A metrics generator206may access member activity and behavior data from the member activity and behavior database132, and may generate one or more metrics208based on the member activity and behavior data. The metrics generator206may store the metrics208in a record of the metric database138. In some example embodiments, the metrics generator206is included in (e.g., is a module of) the A/B reporting system300.

The A/B reporting system300may execute customized A/B tests, and may generate customized A/B reports210based on one or more preferences of a user of the A/B reporting system300. The one or more preferences of a user of the A/B reporting system300may represent one or more customization criteria provided by the user for the customization of an A/B test or the customization of an A/B test report210. In some example embodiments, the generating of the customized A/B reports210includes accessing the metrics208from the metrics generator206or from the metric database138. In certain example embodiments, a first module of the A/B reporting system300generates the metrics208, and a second module of the A/B reporting system300generates the customized A/B reports210.

The A/B reporting system300may receive (e.g., access) the one or more preferences of the user from the client device212. The client device212may be associated with an administrator of the A/B reporting system300(e.g., an experiment owner, a metrics owner, an executive of a company, etc.). The A/B reporting system300may cause the display of a user interface214for receiving a request to perform a customized A/B test, or for receiving a request for a customized A/B test report on the client device212. The user interface214may include one or more input elements216(e.g., a field, a drop-down menu, a button, a list of selection options) for receiving input data from the user of the client device212, and one or more output elements218(e.g., a window, a field, an area, etc.) for presenting a customized A/B report220in the user interface214.

Turning now toFIG. 3, an A/B reporting system300includes a presentation module302, an input module304, a metric generation module306, a report generation module308, an A/B test module310, and a cohort analysis module312, and a database314. In some instances, the database314is external to the A/B reporting system300.

The modules of the A/B reporting system300may be implemented on or executed by a single device, such as an A/B testing device, or on separate devices interconnected via a network. The aforementioned A/B testing device may be, for example, one or more client machines or application servers. The operation of each of the aforementioned modules of the A/B reporting system300will now be described in greater detail in conjunction with the various figures.

In some example embodiments, the presentation module302causes a display of a user interface for receiving a request of a customized report of result data of an A/B test of online content. The user interface may be caused to display on a client device associated with a user. The result data of the A/B test may be generated based on an execution of the A/B test by an A/B test system.

The input module304receives, via one or more input elements of the user interface displayed on the client device, an identifier of the A/B test, a specification of a metric associated with the result data of the A/B test, a specification of a dimension of the metric, the dimension being a data field of the metric, a specification of a location of the result data of the A/B test in a database associated with the A/B test system, an identifier of a time (e.g., a time range), a request to generate the customized report, or a suitable combination thereof.

In some example embodiments, the one or more elements of the user interface include a metric input element that presents an option to select the metric from one or more existing metrics associated with the result data of the A/B test. In some example embodiments, the one or more elements of the user interface include a metric input element that presents an option to define the metric. The metric may be defined by a user of the A/B reporting system300.

In certain example embodiments, the one or more elements of the user interface include a dimension input element that presents an option to select a product-level dimension from one or more dimensions associated with the metric. The product-level dimension may represent a feature of a product. An example of a product-level dimension is a device type (e.g., a desktop, a tablet, a smartphone, a specific brand of a device, etc.). For instance, a metric name “pageviews” may be associated with a product-level dimension “device type” that has a value of “iPhone.”

In various example embodiments, the one or more elements of the user interface include a dimension input element that presents an option to select a member-level dimension from one or more dimensions associated with the metric. The member-level dimension may represent an attribute associated with a member of the SNS. Examples of attributes associated with a member are a title, an industry, a seniority level, a geographical location, etc. According to some example embodiments, the one or more elements of the user interface include a dimension input element that presents an option to define the dimension. The dimension may be defined by a user of the A/B reporting system300.

The metric generation module306accesses the result data of the A/B test from the database associated with the A/B test system based on the specification of the location of the result data. The metric generation module306also generates the metric based on the identifier of the A/B test, the specification of the metric, and the result data of the A/B test.

The report generation module308generates the customized report pertaining to the dimension of the metric based on the generated metric and the specification of the dimension of the metric.

The presentation module302causes a display of the customized report in an output element of the user interface of the client device associated with the user.

The A/B test module310executes A/B tests. In some example embodiments, the input module302receives, via the one or more input elements of the user interface displayed on the client device, a specification of an assignment of one or more members of the SNS to one or more variants of the A/B test, and a request to execute the A/B test based on the specification of the assignment. The A/B test module310executes the A/B test based on the specification of the assignment. The executing results in a generation of the result data of the A/B test.

The cohort analysis module312performing a cohort analysis pertaining to a cohort. In some example embodiments, the cohort includes a number of members of the SNS who exhibited a particular behavior during a particular period of time. According to various example embodiments, the input module302receives a specification of a cohort via the one or more elements of the user interface of the client device. The cohort analysis module312identifies the result data of the A/B test pertaining to the cohort based on member identifiers of the members of the cohort, and performs a cohort analysis pertaining to the cohort based on the result data of the A/B test identified to pertain to the cohort and result data generated during a post-A/B test period of monitoring activity of the members of the cohort.

To perform one or more of its functionalities, the A/B reporting system300may communicate with one or more other systems. For example, an integration engine may integrate the A/B reporting system300with one or more email server(s), web server(s), one or more databases, or other servers, systems, or repositories.

Any one or more of the modules described herein may be implemented using hardware (e.g., one or more processors of a machine) or a combination of hardware and software. For example, any module described herein may configure a hardware processor (e.g., among one or more processors of a machine) to perform the operations described herein for that module. In some example embodiments, any one or more of the modules described herein may comprise one or more hardware processors and may be configured to perform the operations described herein. In certain example embodiments, one or more hardware processors are configured to include any one or more of the modules described herein.

Moreover, any two or more of these modules may be combined into a single module, and the functions described herein for a single module may be subdivided among multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices. The multiple machines, databases, or devices are communicatively coupled to enable communications between the multiple machines, databases, or devices. The modules themselves are communicatively coupled (e.g., via appropriate interfaces) to each other and to various data sources, so as to allow information to be passed between the applications so as to allow the applications to share and access common data. Furthermore, the modules may access one or more databases314(e.g., database128,130,132,136,138, or140).

FIG. 4is a flowchart illustrating an example method400, consistent with various embodiments described herein. The method400may be performed at least in part by, for example, the A/B reporting system300illustrated inFIG. 3(or an apparatus having similar modules, such as one or more client machines or application servers).

At operation402, the presentation module302causes a display of a user interface for receiving a request of a customized report of result data of an A/B test of online content. The user interface is caused to display on a client device associated with a user. The result data of the A/B test may be generated based on an execution of the A/B test by an A/B test system.

At operation404, the input module304receives, via one or more input elements of the user interface displayed on the client device, an identifier of the A/B test, a specification of a metric associated with the result data of the A/B test, a specification of a dimension of the metric, the dimension being a data field of the metric, a specification of a location of the result data of the A/B test in a database associated with the A/B test system, and a request to generate the customized report. The input module304receives, via one or more input elements of the user interface displayed on the client device, an identifier of a time (e.g., a time range).

In some example embodiments, the one or more elements of the user interface include a metric input element that presents an option to select the metric from one or more existing metrics associated with the result data of the A/B test. In certain example embodiments, the one or more elements of the user interface include a dimension input element that presents an option to select a product-level dimension from one or more dimensions associated with the metric. The product-level dimension represents a feature of a product. In various example embodiments, the one or more elements of the user interface include a dimension input element that presents an option to select a member-level dimension from one or more dimensions associated with the metric. The member-level dimension represents an attribute associated with a member of the SNS. Consistent with some example embodiments, the one or more elements of the user interface include a dimension input element that presents an option to define the dimension.

At operation406, the metric generation module306accesses the result data of the A/B test from the database associated with the A/B test system based on the specification of the location of the result data.

At operation408, the metric generation module306generates the metric based on the identifier of the A/B test, the specification of the metric, and the result data of the A/B test.

At operation410, the report generation module308generates the customized report pertaining to the dimension of the metric based on the generated metric and the specification of the dimension of the metric.

At operation412, the presentation module302causes a display of the customized report in an output element of the user interface of the client device associated with the user.

It is contemplated that the operations of method400may incorporate any of the other features disclosed herein. Various operations in the method400may be omitted or rearranged, as necessary.

As shown inFIG. 5, method400may include one or more of operations502or504, according to some example embodiments. Operation502may be performed after operation404, in which the input module304receives, via one or more input elements of the user interface displayed on the client device, an identifier of the A/B test, a specification of a metric associated with the result data of the A/B test, a specification of a dimension of the metric, the dimension being a data field of the metric, a specification of a location of the result data of the A/B test in a database associated with the A/B test system, and a request to generate the customized report.

At operation502, the input module30receives, via the one or more input elements of the user interface displayed on the client device, a specification of an assignment of one or more members of a social networking service (SNS) to one or more variants of the A/B test, and a request to execute the A/B test based on the specification of the assignment.

Operation504is performed after operation502. At operation504, the A/B test module310executes the A/B test based on the specification of the assignment. The executing results in a generation of the result data of the A/B test.

As shown inFIG. 6, method400may include one or more of operations602,604, or606, according to some example embodiments. Operation602may be performed after operation402, in which the presentation module302causes a display of a user interface for receiving a request of a customized report of result data of an A/B test of online content. In some example embodiments, the one or more elements of the user interface include a metric input element that presents an option to define the metric.

At operation602, the input module304receives an indication of a selection of the option to define the metric from the client device associated with the user.

Operation604may be performed after operation602. At operation604, the presentation module302causes a display of a further one or more input elements of the user interface. The further one or more input elements correspond to a metric schema that represents one or more dimensions to be included in the defined metric.

Operation606may be performed as part (e.g., a precursor task, a subroutine, or a portion) of operation404, in which the input module304receives, via one or more input elements of the user interface displayed on the client device, an identifier of the A/B test, a specification of a metric associated with the result data of the A/B test, a specification of a dimension of the metric, the dimension being a data field of the metric, a specification of a location of the result data of the A/B test in a database associated with the A/B test system, and a request to generate the customized report. At operation606, the input module304receives metric definition input via the further one or more input elements of the user interface from the client device. The metric definition input may specify the one or more dimensions of the defined metric.

As shown inFIG. 7, method400may include one or more of operations702or704, according to some example embodiments. Operation702may be performed after operation606of method400illustrated inFIG. 6, in which the input module304receives metric definition input via the further one or more input elements of the user interface from the client device.

At operation702, the input module304determines that the defined metric includes an error based on a comparison of the metric definition input and the metric schema.

Operation702may be performed after operation702. At operation704, the presentation module302causes a display of a request to correct the error in the user interface of the client device.

The input module304may, in response to the presentation module302causing a display of a request to correct the error, receive additional input via the further one or more input elements of the user interface from the client device. The additional input may include corrected metric definition input.

As shown inFIG. 8, method400may include one or more of the operations802,804, or806, according to some example embodiments. Operation802may be performed after operation404, in which the input module304receives, via one or more input elements of the user interface displayed on the client device, an identifier of the A/B test, a specification of a metric associated with the result data of the A/B test, a specification of a dimension of the metric, the dimension being a data field of the metric, a specification of a location of the result data of the A/B test in a database associated with the A/B test system, and a request to generate the customized report.

At operation802, the input module304receives a specification (e.g., a list of member identifiers of members of the SNS) of a cohort via the one or more elements of the user interface of the client device. In some example embodiments, the cohort includes a number of members of the SNS who exhibited a particular behavior during a particular period of time. In some example embodiments, the cohort includes a number of members of the SNS who have a member attribute in common.

At operation804, the cohort analysis module312identifies the result data of the A/B test pertaining to the cohort based on member identifiers of the members of the cohort.

At operation806, the cohort analysis module312performs a cohort analysis pertaining to the cohort. The cohort analysis may be based on the result data of the A/B test identified to pertain to the cohort, result data generated during a post-A/B test period of monitoring activity of the members of the cohort, or both.

As shown inFIG. 9, method400may include one or more of the operations902,904,906, or908, according to some example embodiments. Operation902may be performed as part of operation806of method400illustrated inFIG. 8, in which the cohort analysis module312performs a cohort analysis pertaining to the cohort.

At operation902, the cohort analysis module312accesses the result data of the A/B test pertaining to the cohort. The result data of the A/B test pertaining to the cohort may be stored in and accessed from a record of the cohort database140.

At operation904, the cohort analysis module312accesses an indication of an assignment of the members of the cohort to one or more variants of the A/B test. In some instances, the indication of an assignment of the members of the cohort to one or more variants of the A/B test may be received from the client device. In certain instances, the indication of an assignment of the members of the cohort to one or more variants of the A/B test may be stored in and accessed from a record of the cohort database140.

At operation906, the cohort analysis module312monitors the activity of the members of the cohort during the post-A/B test period. The monitoring of the activity of the members of the cohort may be based on tracking interactions by the members of the cohort with the SNS during the post-A/B test period. The tracking of interactions by the members of the cohort with the SNS may be performed by one or more modules of the A/B reporting system300or by another system associated with the social networking system120.

At operation908, the cohort analysis module312generates cohort analysis results based on a comparison of the result data of the A/B test identified to pertain to the cohort and the monitored activity of the members of the cohort during the post-A/B test period in light of the indication of the assignment of the members of the cohort to the one or more variants of the A/B test.

FIG. 10illustrates an example portion of a user interface1000, according to various embodiments. The user interface is displayed on a client device associated with a user of the A/B reporting system300, such as an experiment owner, a metric owner, an executive of a company, etc. As shown inFIG. 10, the user interface1000may include an area for requesting the generating of A/B experiments (e.g., area1002) and an area for requesting the generating of A/B test reports on demand (e.g., area1004). By selecting area1002, the user may request the generation of an A/B experiment. By selecting area1004, the user may request the generation of an A/B test report on demand.

The user interface1000may display information about existing A/B experiments. For example, area1006displays identifier “1337556” for the existing experiment “SSU CTR prediction” for the time range “6.22.2015-Present.” Area1008displays identifier “1332466” for existing experiment “SSU CTR prediction” for the time range “6.10.2015-6.22.2015.”

The user interface1000may also display information about existing A/B test reports. For example, area1010identifies the test report “scin” for the time range “4/29-5/12,” area1012identifies the test report “scin” for the time range “4/29-5/11,” and area1014identifies the test report “scin” for the time starting on “4/29.”

As shown inFIG. 10, area1016of user interface1000facilitates the input, by the user, of a name for an on-demand A/B test report via input element1018, and of a time (e.g., a date range) associated with the data for the analysis performed in generating the requested A/B test report via input element1020. In some example embodiments, the data should already exist and be stored in a record of a database associated with the A/B reporting system300. In various example embodiments, if the requested date range spans multiple experiments or ramps of an experiment, the traffic allocation of the variants should remain consistent during the date range.

The user interface1000also includes a button1022to facilitate the indication, by the user, that the A/B experiment is a member-based experiment, and a button1024to indicate that the analysis is not a cohort analysis.

FIG. 11illustrates an example portion of a user interface1100, according to various embodiments. A user may have an option1102to select an existing metric for an on-demand A/B test report, or an option1106to request the generation of a new metric. The drop-down menu1104facilitates a selection, by the user, of a metric from one or more existing metrics. Various input elements of the user interface1110facilitate the specification, by the user, of various information pertaining to the user-defined metric. For example, input element1108is used to provide a specification of a location of the user-defined metrics for the A/B test in a database associated with the A/B test system, input element1110is used to provide metric metadata, and input element1112is used to provide a specification of (e.g., to select) a dimension of the metric. The dimension of the metric may be a data field of the metric.

FIG. 12illustrates an example portion of a file that specifies the fields of a metric schema, according to various example embodiments. In some example embodiments, the user-defined metric should comport with the metric schema. The A/B reporting system300may, in response to receiving metric definition input for the user-defined metric, determine that the defined metric includes an error based on a comparison of the metric definition input and the metric schema. The A/B reporting system300may cause a display of a request to correct the error in the user interface of the client device, and may, in response to the displaying of the request to correct the error, receive further input to correct the error.

FIG. 13illustrates an example portion of a user interface1300, according to various embodiments. Area1302of the user interface1300may facilitate the specification of the assignment, by the user, of members to various treatments of an A/B experiment. For example, the user may select an existing assignment of members from a drop-down menu1304. The determining of the member assignment to an experiment, by the A/B reporting system300, may be based on the testkey associated with the experiment and based on the selected date range.

Alternately, the user may request, via area1306of the user interface1300, a customized assignment of members to variants of an A/B experiment. In some example embodiments, the user defines the experiment population by providing a member list that includes identifiers of members.

As shown inFIG. 13, area1308of the user interface1300facilitates the additional cohort selection by the user. Input element1310of the user interface1300facilitates the providing, by the user, of a location of a member list of the members included in the cohort. In some example embodiments, the member list is a file that includes one or more member identifiers (e.g., member IDs) and that is stored in cohort database140.

In some example embodiments, by default, the cohort is defined as the members who are included in the experiment population. In certain example embodiments, if the user provides a list of member IDs as the cohort, the A/B reporting system300filters down the experiment population to include only the members included in the cohort.

FIG. 14illustrates an example portion of a file that specifies the fields of an assignment schema for a customized assignment file, according to various example embodiments. In some example embodiments, the user-defined member assignment should comport with the assignment schema.

The A/B reporting system300may, in response to receiving a customized assignment file for the customized member assignment, determine that the customized assignment file includes an error based on a comparison of the customized assignment file and the assignment schema. The A/B reporting system300may cause a display of a request to correct the error in the user interface of the client device, and may, in response to the displaying of the request to correct the error, receive further input to correct the error.

Example Mobile Device

FIG. 15is a block diagram illustrating the mobile device1500, according to an example embodiment. The mobile device may correspond to, for example, one or more client machines or application servers. One or more of the modules of the system200illustrated inFIG. 2may be implemented on or executed by the mobile device1500. The mobile device1500may include a processor1502. The processor1502may be any of a variety of different types of commercially available processors1502suitable for mobile devices1500(for example, an XScale architecture microprocessor, a microprocessor without interlocked pipeline stages (MIPS) architecture processor, or another type of processor1502). A memory1504, such as a random access memory (RAM), a flash memory, or other type of memory, is typically accessible to the processor1502. The memory1504may be adapted to store an operating system (OS)1506, as well as application programs1508, such as a mobile location enabled application that may provide LBSs to a user. The processor1502may be coupled, either directly or via appropriate intermediary hardware, to a display1510and to one or more input/output (I/O) devices1512, such as a keypad, a touch panel sensor, a microphone, and the like. Similarly, in some embodiments, the processor1502may be coupled to a transceiver1514that interfaces with an antenna1516. The transceiver1514may be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna1516, depending on the nature of the mobile device1500. Further, in some configurations, a GPS receiver1518may also make use of the antenna1516to receive GPS signals.

Modules, Components and Logic

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors or processor-implemented modules, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the one or more processors or processor-implemented modules may be distributed across a number of locations.

Electronic Apparatus and System

Example Machine Architecture and Machine-Readable Medium

FIG. 16is a block diagram illustrating components of a machine1600, according to some example embodiments, able to read instructions1624from a machine-readable medium1622(e.g., a non-transitory machine-readable medium, a machine-readable storage medium, a computer-readable storage medium, or any suitable combination thereof) and perform any one or more of the methodologies discussed herein, in whole or in part. Specifically,FIG. 16shows the machine1600in the example form of a computer system (e.g., a computer) within which the instructions1624(e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine1600to perform any one or more of the methodologies discussed herein may be executed, in whole or in part.

The machine1600includes a processor1602(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), or any suitable combination thereof), a main memory1604, and a static memory1606, which are configured to communicate with each other via a bus1608. The processor1602may contain microcircuits that are configurable, temporarily or permanently, by some or all of the instructions1624such that the processor1602is configurable to perform any one or more of the methodologies described herein, in whole or in part. For example, a set of one or more microcircuits of the processor1602may be configurable to execute one or more modules (e.g., software modules) described herein.

The machine1600may further include a graphics display1610(e.g., a plasma display panel (PDP), a light emitting diode (LED) display, a liquid crystal display (LCD), a projector, a cathode ray tube (CRT), or any other display capable of displaying graphics or video). The machine1600may also include an alphanumeric input device1612(e.g., a keyboard or keypad), a cursor control device1614(e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, an eye tracking device, or other pointing instrument), a storage unit1616, an audio generation device1618(e.g., a sound card, an amplifier, a speaker, a headphone jack, or any suitable combination thereof), and a network interface device1620.

The storage unit1616includes the machine-readable medium1622(e.g., a tangible and non-transitory machine-readable storage medium) on which are stored the instructions1624embodying any one or more of the methodologies or functions described herein. The instructions1624may also reside, completely or at least partially, within the main memory1604, within the processor1602(e.g., within the processor's cache memory), or both, before or during execution thereof by the machine1600. Accordingly, the main memory1604and the processor1602may be considered machine-readable media (e.g., tangible and non-transitory machine-readable media). The instructions1624may be transmitted or received over the network1626via the network interface device1620. For example, the network interface device1620may communicate the instructions1624using any one or more transfer protocols (e.g., hypertext transfer protocol (HTTP)).

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute software modules (e.g., code stored or otherwise embodied on a machine-readable medium or in a transmission medium), hardware modules, or any suitable combination thereof. A “hardware module” is a tangible (e.g., non-transitory) unit capable of performing certain operations and may be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

Accordingly, the phrase “hardware module” should be understood to encompass a tangible entity, and such a tangible entity may be physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, “hardware-implemented module” refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where a hardware module comprises a general-purpose processor configured by software to become a special-purpose processor, the general-purpose processor may be configured as respectively different special-purpose processors (e.g., comprising different hardware modules) at different times. Software (e.g., a software module) may accordingly configure one or more processors, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.