Methods and apparatus to calibrate return path data for audience measurement

Example apparatus disclosed herein include a return path data classifier to classify a first viewing period associated with segments of return path data received from a set top box into tuning classifications based on the segments of the return path data; calculate a total reported tuning duration for the first viewing period when the first viewing period is classified as live or playback tuning; and compare the total reported tuning duration to a duration threshold to determine whether the segments of return path data associated with the first viewing period are valid. The example apparatus also includes a return path data rectifier to rectify missing tuning data associated with a second viewing period based on tuning data included in the segments of return path data associated with the first viewing period when the segments of the return path data associated with the first viewing period are determined to be valid.

FIELD OF THE DISCLOSURE

This disclosure relates generally to audience measurement, and, more particularly, to methods and apparatus to calibrate return path data for audience measurement.

BACKGROUND

Many households access media through set top boxes (STBs) provided by media providers cable media providers, satellite media providers, etc.). Some STBs are equipped to report tuning data, which is indicative of the media accessed by the STBs, back to the media providers. Tuning data reported back to media providers via STBs is sometimes referred to as return path data (RPD). RPD tuning data may be used by audience measurement entities to monitor people's exposure to media.

DETAILED DESCRIPTION

In the past, audience measurement entities (AMEs) have relied on audience measurement panelists to collect and/or measure audience measurement data used to generate audience metrics such as, for example, media ratings indicative of the number of households tuned to particular media programs at a given point in time. Typically, media ratings, or simply ratings, are expressed as a percentage of households relative to a population of interest, also referred to as a population universe. For example, the population of interest may be an entire country or a more specific geographic region (e.g., a designated market area (DMA) or other local market area). DMAs may range in size from several million households for a large metropolitan area down to a few thousand households in a rural market area.

Typically, national ratings are generated based on audience measurement data collected via people meters installed in statistically selected panelist households. The people meters monitor the exposure of panelists to media and automatically report such data to an AME for subsequent analysis and processing. In addition, some AMEs rely on additional panelists in the smaller local market areas to record their media consumption behavior in paper diaries over specified periods of time and then mail the completed diaries to the AME for subsequent analysis and processing. While paper diaries provide a relatively inexpensive method to increase the audience measurement sample size, what panelists record in the paper diaries may not always be accurate, thereby introducing potential biases in the data. Furthermore, diary samples often favor highly rated broadcast stations while neglecting smaller broadcast or cable networks such that the collected panel data may not be fully representative for reliable analysis.

As technology has advanced, AMEs have turned to tuning data collected, measured, and/or reported from RPD devices as an alternate source of data that may be used to generate ratings for media and/or other audience measurement metrics. As used herein, an RPD device refers to any type of media device (e.g., a STB or other similar device) that is capable of accessing media from a media provider and reporting tuning data regarding the media accessed back to the media provider. Such tuning data is referred to herein as RPD tuning data or simply RPD. Using RPD tuning data for audience metrics has the advantage that it is relatively inexpensive to obtain. For example, RPD timing data may be obtained substantially automatically based on software installed on processors associated with the RPD devices reporting the RPD tuning data via any suitable network (e.g., the Internet). Not only is RPD tuning data relatively inexpensive to collect based on modem computer technology that makes the reporting of such RPD tuning data possible, RPD tuning data is also advantageous in that it may be collected from much larger quantities of households than possible through traditional audience measurement panels. For example, RPD tuning data may be collected from virtually every household that includes an RPD device because the reporting of RPD tuning data is often set as the default option for such devices at the time of manufacture.

While RPD tuning data provides these advantages, there are challenges with relying exclusively, or even partially, on RPD tuning data for purposes of audience measurement. Even where a household has an RPD device to report tuning data (e.g., the household subscribes to a media content provider), the same household may have other media devices that are not capable of reporting RPD tuning data. Such devices are referred to herein as non-RPD devices. As a result, RPD tuning data collected in such households may not account for media exposure of audience members in non-RPD devices. Therefore, in some examples RPD tuning data reported for a household may not account for all media exposure in the household and, thus, may be biased or illogical. Furthermore, the STBs that produce RPD are often not turned off reliably. As such, when a television is turned off, the STB may still be on and will report RPD during the time the television was turned off. Additionally, when some STBs undergo software updates, they provide RPD that indicates all stations as being active. Thus, while RPD can be collected for a wide array of people, it may be missing tuning data or providing tuning data that was never actually watched.

Example methods, apparatus, and articles of manufacture disclosed herein overcome at least some of the limitations associated with determining media ratings in local markets based on local RPD tuning data by using panel tuning data collected in the surrounding region to the local market to calibrate the RPD tuning data to correct for biases in the RPD tuning data.

Examples disclosed herein calibrate RPD tuning data by classifying viewing periods associated with one or more segments of return path data received from a set top box into one or more tuning classifications (e.g., live tuning, playback tuning, etc.) based on the one or more segments of the return path data. In examples disclosed herein a viewing period can cover multiple segments of tuning data in the return path data. For example, a viewing period may cover one minute and, as such, there may be 1440 viewing periods for a given day, representative of the 1440 total minutes in a day. Alternatively, the viewing period may cover any period of time (partial minutes, multiple minutes, hours, days, weeks, etc.). Segments of tuning data may represent any segment of time e.g., seconds, minutes, hours, days, etc.) for which RPD tuning data is to be calibrated (e.g., corresponding to the granularity of tuning data to be calibrated).

In some examples disclosed herein, a total reported tuning duration for a viewing period may be calculated when the viewing period is classified as at least one of live or playback tuning. For example, the total reported tuning duration may be calculated by combining tuning segments for a viewing period reported by a STB. In some examples, the segments of tuning data have respective reported tuning durations that contribute to the total reported tuning duration for a viewing period. For example, each segment of a viewing period may have a corresponding reported tuning duration that is combined to contribute to the total reported tuning duration for the viewing period. In some examples, the segments may combine to generate a total reported tuning duration that exceeds the viewing period, which is indicative of error(s) in the RPD. Examples disclosed herein calibrate the RPD tuning data to correct for such errors. Thus, the total reported tuning duration may be compared to a duration threshold (e.g., a value greater than the viewing period) to determine whether segments of return path data associated with a viewing period are valid. In some examples, calibration is also based on a number of tuning sources (e.g., channel numbers, station codes, etc.) tuned by a set top box during a viewing period as determined based on the segments of return path data associated with the viewing period.

In some examples disclosed herein, the segments of return path data associated with the viewing period are identified as valid when the total reported tuning duration satisfies the duration threshold and the number of tuning sources tuned during the viewing period satisfies a tuning source threshold. The tuning source threshold may be determined based on a particular media provider, for example.

Once the RPD tuning data is identified as valid, it may be utilized to rectify missing tuning data associated with a second viewing period. For example, when the segments of the return path data associated with a first viewing period are determined to be valid, the missing return path data associated with the second viewing period may be replaced with the timing data included in the segments of return path data associated with the first viewing period. For example, segments for a first viewing period may be identified as valid and may be associated with program A. As such, the missing return path data may be rectified to be associated with program A, for example. However, as detailed below, other rules may be applied to rectify and/or calibrate RPD.

FIG. 1is an example environment100including an example media calibration module122to calibrate return path data for audience measurement in accordance with the teachings of this disclosure. In the illustrated example, an example media provider102provides media to subscribers and collects RPD tuning data indicative of the subscribers accessing the media. The media provider102may provide the RPD tuning data to an example audience measurement entity (AME)104to enable the AME104to generate audience measurement metrics. In some examples, the media provider102and the AME104communicate via an example network106such as, for example, the Internet.

As shown inFIG. 1, the example environment100includes an example non-panelist household108, and an example panelist household110. The panelist household110represents households that have members that have enrolled as panelists with the AME104, whereas non-panelist household108represents households that are not enlisted with the AME104. There may be any number of panelist households110and non-panelist households108in the environment100. In some examples, panelists correspond to a statistically selected subset of all potential audience members that is representative of a population of interest. In some such panel-based monitoring systems, the panelists agree to provide detailed demographic information about themselves. In this manner, detailed exposure metrics are generated based on collected media exposure data and associated user demographics, which can then be statistically extrapolated to an entire population of interest (e.g., a local market, a national market, a demographic segment, etc.).

In the illustrated example, the non-panelist household108includes an example RPD device112and an example non-RPD device114. The panelist household110differs in that the panelist household110includes an example RPD device116, an example non-RPD device118, and an example meter120. However, the non-panelist household108can include any number of RPD devices112and/or non-RPD devices114. Likewise, the panelist household110can include any number of RPD devices116and/or non-RPD devices118and/or meters120. As described above, an RPD device, as used herein, is any type of media device capable of accessing media from a media provider102and reporting RPD tuning data back to the media provider. By contrast, a non-RPD device, as used herein, refers to any type of media device that is capable of accessing and/or playing media from a media provider102but that does not have the capability to report RPD tuning data back to the media provider102, or does not have such capabilities enabled.

In the illustrated example ofFIG. 1, the non-panelist household108and the panelist household110include the RPD devices112,116because the households are subscribers to the media provider102. In some examples, the RPD devices112,116are provided by the media provider102when the households initially become subscribers to enable access to media generated by media provider102. As shown in the illustrated example, the RPD devices112,116may access media from the media provider102and report RPD tuning data to the media provider102via the network106.

As shown in the illustrated example, the households108,110may include non-RPD devices114,118in addition to the RPD devices112,116. However, a household may have any number of RPD devices and/or non-RPD devices, but does not have to have any RPD devices (i.e., capable of reporting RPD tuning data that is available to the AME104) or non-RPD devices.

In the illustrated example, the RPD devices112,116may be standalone devices (e.g., STBs, cable modems, embedded multimedia adapters (EMTAs)) that connect to separate media presentation devices, such as, television sets, radios, smartphones, tablets, computers, or any other device capable of playing the media accessed by the RPD devices112,116. In some examples, the RPD devices112,116may be integrated with a corresponding media presentation device capable of playing the media accessed by the RPD device (e.g., a smart television). Similarly, the non-RPD devices114,118may be integrated media presentations devices or standalone devices (e.g., STBs) that connect to separate media presentation devices.

As described herein, RPD devices are capable of reporting RPD tuning data to a media provider102, but non-RPD devices do not. Thus, in the illustrated example, RPD tuning data collected by the media provider102would be limited to media accessed via the RPD devices112,116. Such data is incomplete as it does not represent the complete exposure to media by all households. For example, the RPD tuning data would not indicate any media exposure by audience members using only non-RPD devices114,118. Further, while the RPD tuning data would convey some media to which audience members in the households108,110were exposed, any media accessed via the non-RPD devices114,118is not accounted for in the reported RPD tuning data.

While the RPD tuning data collected from the RPD devices112,116is insufficient to fully account for all media accessed in any of the households, the AME104is at least able to fully account for much, and possibly all, of media accessed at the panelist household110. This is possible because the panelist household110is provided with the metering device120to track and/or monitor media played in the households110and report such to the AME104(e.g., via the network106). In some examples, the metering device120also tracks and reports who is being exposed to the media being played so that the media exposure can be associated with particular individuals and their associated demographics previously collected when the household members enrolled as panelists. While a single metering device120is shown in the panelist household110to monitor both the RPD device116and the non-RPD device118, in some examples, a separate metering device120may be associated with each device to independently track and report media accessed by each device to the AME104.

In the illustrated example ofFIG. 1, the AME104includes the example RPD calibration module122to calibrate RPD tuning data used to complete ratings data as described more fully below. More particularly, the RPD calibration module122uses panel tuning data included in audience measurement data collected from panelist households (e.g., from the metering device120of the panelist household110) to calibrate RPD. In some examples, the RPD calibration module122determines whether RPD is complete and logical (e.g., validating tuning segments of a viewing period) and rectifies incomplete tuning data. In some examples, the RPD calibration module122identifies tuning across viewing periods missing tuning data, with such tuning being identified based on adjacent tuning data as reported in the RPD. For example, RPD received from the RPD device116may be missing multiple segments of tuning data for a given viewing period. As such, the RPD calibration module122may identify segments of tuning data that occur prior to and subsequent the missing segments, and modify (e.g., bridge the gap) the missing segments based on bridging rules. The bridging rules are discussed in more detail below in connection withFIG. 2. In some examples, the RPD calibration module122generates a grid of segments for viewing periods for each STB included in the RPD. For example, the RPD calibration module may receive RPD from each RPD device112,116and generate a grid of segments for each viewing period. In some examples, the RPD calibration module122then evaluates the segments to determine if the RPD is valid (e.g., usable) for reporting for a given day. Examples disclosed herein calibrate RPD without the need or expense of employing paper diaries or having a large sample size of panelists specifically located within the local market area.

FIG. 2is an example implementation of the example RPD calibration module122ofFIG. 1. The example RPD calibration module122includes an example communications interface202, an example RPD classifier204, an example RPD validator206, an example RPD rectifier208, an example panel tuning data database210, and an example RPD tuning data database212.

The example RPD calibration module122is provided with the example communications interface202to communicate with the metering device120installed in the panelist household110. That is, the metering device120may report audience measurement data to the AME104that is received by the communications interface202. The communications interface202may receive audience measurement data from other panelist households not represented in the illustrated example. The collected audience measurement data includes panel tuning data, which may be stored in the panel tuning data database210. The panel tuning data may include an indication of the media accessed via the associated media devices (e.g., the RPD device116or the non-RPD device118). In the illustrated example, the panel tuning data includes an identifier of the particular media device used to access the media and/or an indication of whether the media device is capable of reporting RPD tuning data (i.e., whether the media device is an RPD device). In some examples, the media accessed by the media devices may be uniquely identified by the panel tuning data. In some examples, the panel tuning data may identify a particular source of media (e.g., a station ID) from which the particular media may be identified based on an associated timestamp included in the panel tuning data.

In the illustrated example, the communications interface202of the RPD calibration module122receives RPD tuning data from the media provider102. The media provider102collects the RPD tuning data reported from RPD devices (e.g., the RPD devices112,116) accessing media provided by the media provider102. In some examples, the communications interface202may receive the RPD tuning data directly from the RPD devices112,116independent of communications between the AME104and the media provider102. The RPD tuning data may be stored in the RPD tuning data database212. Similar to the panel tuning data, the RPD tuning data includes a media identifier (e.g., a unique identifier, a station ID with an associated timestamp, etc.) to identify the media accessed by the RPD devices.

To classify the RPD tuning data, the RPD classifier204receives the RPD tuning data for the non-panelist household108and the panelist household110. In some examples, the RPD classifier204receives the RPD tuning data from the communications interface202. In some examples, the RPD classifier204may retrieve the RPD tuning data from the RPD tuning data database212. Once the RPD tuning data has been received, the RPD classifier204classifies each viewing period corresponding to the RPD tuning data. For example, the RPD classifier204may receive RPD tuning data indicative of one day of tuning data. As such, the RPD classifier204may generate a grid indicative of the 1440 minutes in a day. Each section of the grid represents a viewing period (e.g., a viewing period corresponds to a minute in this example, but viewing periods may have other durations in other examples.). The example RPD classifier204classifies each viewing period in the grid. For example, the RPD classifier204may classify each viewing period as either live tuning, playback tuning, OFF, stand-by and/or gap tuning. To classify each viewing period, the RPD classifier204may classify each segment of RPD of the viewing period based on descriptive data included with the RPD segment, and compare the classification to a threshold. For example, the RPD classifier204may identify that 29 segments (e.g., seconds) of the viewing period correspond to live tuning based on descriptive data included with the RPD segments, while the remaining segments correspond to playback tuning based on descriptive data included with the RPD segments. In such an example, the RPD classifier204classifies that viewing period as playback tuning based on the majority of the segments corresponding to playback tuning. In some examples, the RPD classifier204may classify the viewing period as both live tuning and playback tuning. In some examples, the RPD classifier204may classify a viewing period as OFF when the RPD tuning data is indicative of the STB being turned off. The example RPD classifier204may classify a viewing period as gap tuning if there is missing or illogical tuning data, or if there is not a sufficient amount of RPD tuning data to classify the viewing period. In some examples, the RPD classifier204may utilize heartbeat data (e.g., information indicative of a STB functioning properly) to classify a viewing period. For example, if heartbeat data is expected to be generated for a specific viewing period or for a specific period of time, the RPD classifier204may classify that viewing period and/or viewing periods as gap tuning if the heartbeat data is missing. As an example, for a certain type of STB, heartbeat data is expected at or around 12:00 AM, and a majority of STBs of this type are known to generate heartbeat data between 11:45 PM and 12:15 AM. As such, if the RPD classifier204identifies heartbeat data for a certain STB at 2:00 AM, the RPD classifier204may identify the viewing periods between 12:15 AM and 2:00 AM as gap tuning. In another example, heartbeat data may be expected every eight hours for a given type of STB, with a majority of STBs of that type generating heartbeat data every seven and a half to eight and a half hours. In such an example, the RPD classifier204may identify heartbeat data for such STB at 1:00 AM and heartbeat data for the same STB at 10:00 AM. In that example, the RPD classifier204may classify the viewing periods between 9:30 AM and 10:00 AM as gap tuning.

Once the RPD classifier204has classified the viewing periods of interest, the RPD classifier204further classifies the viewing periods that were classified as live tuning and/or playback tuning. For example, for each viewing period that was classified as live tuning and/or playback tuning, the RPD classifier204calculates a total reported tuning duration for the given viewing period and compares it to a threshold. For example, the RPD classifier204may calculate a total reported tuning duration by accumulating individual reported tuning durations for respective RPD segments included in a viewing period, such as a given minute of a day. The RPD classifier204may calculate the total reported tuning duration based on start/end times for the classified viewing period. As an example, based on descriptive data of the RPD, the RPD classifier204may identify live tuning to station XYZ from 1:01:05 PM to 1:03:15 PM, playback tuning to station UVW from 1:01:01 PM to 1:15:08 PM, and live tuning to station RST from 1:02:33 PM to 1:45:00 PM. In such an example, the RPD classifier204will calculate a total reported tuning duration of 147 seconds for the viewing period representative of 1:02:00 PM (corresponding to 60 seconds for station XYZ, 60 seconds for station UVW, and 27 seconds for station RST). In this example, the viewing period represents a minute, so the threshold may be set at 65 seconds. As such, the RPD classifier204may classify the viewing period for 1:02:00 PM as an overlapping minute because the total reported tuning duration of 147 seconds exceeds the threshold of 65 seconds.

For the viewing periods classified as overlapping minutes, the RPD classifier204calculates a number of tuning sources (e.g., channel numbers, station codes, etc.) that account for at least a threshold portion of the viewing period. For example, the RPD classifier204may classify a viewing period as conflicted tuning if the number of tuning sources that account for at least 31 seconds of the viewing period exceeds a threshold (e.g., 2 tuning sources, 4 tuning sources, etc.). The RPD classifier204continues to classify the viewing periods until all of the viewing periods have been classified.

In the foregoing example, reported tuning duration was determined in units of seconds. However, in other examples, the reported tuning duration may be determined in other units, such as in portions/fractions, etc. of the viewing period.

Once the RPD tuning data has been classified, the RPD validator206validates the classified RPD tuning data. To validate the RPD tuning data, the RPD validator206generates activity validation data based on the RPD tuning data from the panelist household110. For example, the RPD validator206may generate the activity validation data based on the information received from the RPD device116, the non-RPD device118, and the meter118. In some examples, the RPD validator206may generate the activity validation data based on the panel tuning data stored in the panel tuning data database212. To generate the activity validation data, the RPD validator206generates a grid corresponding to the viewing periods for the reported RPD tuning data. The RPD validator206may further include identifiers (device identifiers, media identifiers, etc.) for each of the viewing periods in the grid. In some examples, the RPD validator206generates the activity validation data prior to the RPD classifier204classifying the RPD tuning data. Once the activity validation data has been generated, the RPD validator206processes the classified RPD tuning data from the RPD classifier204.

In the illustrated example, to validate the classified RDP tuning data, the RPD validator206determines if the RPD tuning data is complete. For example, the RPD validator206may determine 1) if there is a threshold amount of heartbeat data, 2) whether specific information was collected from the RPD tuning data (e.g., the STB was tuned to a certain station and not off during a time period of interest), and/or 3) when the specific information was collected. In some examples, the RPD validator206determines if RPD tuning segment(s) for each viewing period has(have) start and end times that are consistent. For example, when the RPD validator206identifies playback tuning (e.g., time-shifted tuning), the RPD validator206validates that there are two sets of start and end times, one corresponding to the broadcast duration and the other corresponding to the playback duration. The RPD validator206further determines that the playback tuning is valid by determining that the broadcast duration is equal to the playback duration. If the RPD validator206identifies any discrepancies based on the RPD information not satisfying the above criteria, the RPD validator206may edit the RPD tuning data based on the activity validation data or may remove the RPD tuning data from further processing.

In some examples, to edit the RPD tuning data, the RPD validator206identifies any non-residential STBs commercial accounts, multiple dwelling units, etc.) and removes the RPD tuning data from further processing. If information is not available to identify non-residential status, the RPD validator206identifies accounts that are associated with a large number of STBs, for example 20 or more, and removes the RPD information from further processing. Once the non-residential RPD tuning data has been removed, the RPD validator206identities incomplete RPD tuning data that may need to be validated and/or edited. For example, the RPD validator206verities that each segment(s) of RPD tuning data associated with that viewing period is associated with at least one tuning source. If multiple segments of RPD tuning data associated with viewing periods are not associated with a tuning source, the RPD validator206compares the total tuning duration (X) to the total duration of tuning that cannot be mapped (Y). The RPD validator206determines if the ratio of X to Y (X/Y) exceeds a certain threshold. If the RPD validator206determines that X/Y exceeds the threshold, the RPD tuning data is considered unusable and is removed from further processing.

After the RPD tuning data has been classified and validated, the RPD rectifier208identifies tuning sessions (e.g. multiple viewing periods with similar tuning classifications) for the RPD tuning data. The RPD rectifier208may identify the tuning sessions by looking for at least one of a change in station or tuning state channel change, STB turned off, change from live tuning to playback tuning) in the RPD tuning data, or viewing periods identified as gap tuning. The RPD rectifier208then identifies each viewing period in the tuning session and identifies viewing periods that are missing tuning data (e.g., classified as gap tuning).

The RPD rectifier208then modifies the RPD tuning segments for the viewing periods with missing tuning data based on bridging rules. In some examples, the bridging rules include: 1) if the RPD tuning segment is at the start of the tuning session, the segment is rectified to match the tuning data of the following segment; 2) if the RPD tuning segment is at the end of the tuning session, the segment is rectified to match the tuning data of the preceding segment; 3) if segments on either side of the RPD tuning segment classified as gap tuning have the same tuning data, the segment classified as gap tuning is rectified to match that tuning data. If segments on either side of the segment classified as gap tuning have different tuning data, the segment classified as gap timing is assigned tuning data based on one of the following methods: 1) apply a hierarchy whereby, among tuning data on either side of the segment classified as gap tuning, preference is based on: i) live tuning over playback tuning (or vice versa), ii) live tuning or playback tuning over stand-by, etc.; 2) the viewing period of adjacent tuning data is used; or 3) a portion of a segment will be randomly selected. For instances when the portion of the segment is randomly selected, the RPD rectifier208rectifies the segment to include the tuning data of the segment prior to the portion of the segment classified as gap tuning up to the portion of the segment. The RPD rectifier208rectifies the remaining portion of the segment to include tuning data from the segment following the end of the portion of the segment.

Once the RPD rectifier208has rectified the RPD tuning data, the RPD rectifier208determines if the RPD tuning data for a household (e.g., non-panelist household108) is usable in-tab) for a given day. For example, the RPD rectifier208determines that all active STBs for the household (e.g., non-panelist household108) have the same zip code and/or headend. The RPD rectifier208then determines that the remaining segments classified as gap tuning does not exceed a gap tuning threshold (e.g., 10% or some other value). The RPD rectifier208then determines if the segments associated with viewing periods classified as conflicted tuning does not exceed a conflicted tuning threshold (e.g., 3%). Further, the RPD rectifier208may determine that the number of segments associated with viewing periods classified as live tuning does not exceed a live tuning threshold (e.g.,300). In some examples, if the RPD tuning data does not include any missing or illogical data (e.g., the RPD rectifier208was able to rectify all of the RPD tuning data), then the RPD rectifier208may not determine if any segments exceed the gap tuning threshold.

While an example manner of implementing the RPD calibration module122ofFIG. 1is illustrated inFIG. 2, one or more of the elements, processes and/or devices illustrated inFIG. 2may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example communications interface202, the example RPD classifier204, the example RPD validator206, the example RPD rectifier208, and/or, more generally, the example RPD calibration module122ofFIG. 1may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example communications interface202, the example RPD classifier204, the example RPD validator206, the example RPD rectifier208, and/or, more generally, the example RPD calibration module122could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example communications interface202, the example RPD classifier204, the example RPD validator206, the example RPD rectifier208, and/or, more generally, the example RPD calibration module122is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the example RPD calibration module122ofFIG. 1may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated inFIG. 2, and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase “in communication,” including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

“Including” and “comprising” (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim employs any form of “include” or “comprise” (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, when the phrase “at least” is used as the transition term in, for example, a preamble of a claim, it is open-ended in the same manner as the term “comprising” and “including” are open ended. The term “and/or” when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, and (6) B with C.

FIG. 3is a flowchart representative of example machine readable instructions that may be executed to implement the RPD calibration module122ofFIGS. 1 and/or 2. The program ofFIG. 3begins by classifying RPD information (block302). For example, the RPD classifier204may receive RPD tuning data for the non-panelist household108and the panelist household110. The RPD validator206then validates the RPD information (block304). The RPD validator204then determines if the RPD information is valid (block306). If the RPD information is not valid, the process ends. If the RPD information is valid, the RPD rectifier208rectifies the validated RPD information (block308). The RPD rectifier208then determines if the RPD information is indicative of a suitable household (block310). If the RPD information is not indicative of a suitable household, the RPD rectifier208removes the RPD information (block312). If the RPD information is indicative of a suitable household, the process ends.

FIG. 4is a flowchart representative of example machine readable instructions that may be executed to implement the RPD classifier204to classify RPD information and/or to perform the processing at block302ofFIG. 3. The process302ofFIG. 4begins when the RPD classifier204receives RPD tuning data form panelist households and non-panelist households (block402). The RPD classifier204then classifies each viewing period corresponding to the RPD tuning data (block404). For each viewing period classified as live or playback tuning (block406), the RPD classifier204calculates a total reported tuning duration for the given viewing period (block408). The RPD classifier204then determines if the reported tuning duration for the given viewing period exceeds a threshold (block410). If the reported tuning duration does not exceed the threshold, the RPD classifier204determines if all viewing periods have been evaluated (block418). If all viewing periods have been evaluated, the process returns to block302. If all viewing periods have not been evaluated, the process returns to block406to select another viewing period to classify.

However, if the reported tuning duration exceeds the threshold, the RPD classifier204classifies the given viewing period as an overlapping viewing period (block412). The RPD classifier204then determines if the tuning source threshold has been exceeded for the given viewing period (block414). If the tuning source threshold has not been exceeded, the process proceeds to block418to determine if all viewing periods have been evaluated. However, if the tuning source threshold has been exceeded, the RPD classifier204classifies the given viewing period as conflicted tuning (block416). The RPD classifier204then determines if all viewing periods have been evaluated (block418). If all viewing periods have been evaluated, the process returns to block302. If all viewing periods have not been evaluated, the process returns to block406to select another viewing period to classify. The process then returns to block302.

FIG. 5is a flowchart representative of example machine readable instructions that may be executed to implement the RPD validator206to validate RPD information and/or to perform the processing at block304ofFIG. 3. The process304ofFIG. 5begins when the RPD validator206generates activity validation data based on the RPD tuning data from the panelist households (block502). The RPD validator206then determines if the RPD tuning data from the non-panelist households is valid (block504). If the RPD tuning data from the non-panelist households is valid, the process proceeds to block508to adjust tuning data based on the activity validation data. If the RPD tuning data is not valid, the RPD validator determines if the RPD tuning data can be adjusted (block506). If the RPD tuning data cannot be adjusted, the RPD validator206signals that the RPD tuning data cannot be adjusted (block510). If the RPD tuning data can be adjusted, the RPD validator206adjusts the tuning data based on the activity validation data (block508). The process then returns to block304.

FIG. 6is a flowchart representative of example machine readable instructions that may be executed to implement the RPD rectifier208to rectify RPD information and/or to perform the processing at block308ofFIG. 3. The process308ofFIG. 6begins when the RPD rectifier208identifies viewing periods for the validated RPD tuning data (block602). The RPD rectifier208then identifies segments of the viewing period missing tuning data (block604). The RPD rectifier208then modifies segments missing tuning data based on bridging rules (block606). For example, the RPD rectifier208modifies the segments based on the bridging rules detailed above in connection withFIG. 2. The process then ends.

FIG. 7is a block diagram of an example processor platform700structured to execute the instructions ofFIGS. 3-6to implement the RPD calibration module122ofFIG. 1. The processor platform700can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a headset or other wearable device, or any other type of computing device.

The processor platform700of the illustrated example includes a processor712. The processor712of the illustrated example is hardware. For example, the processor712can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor implements the example RPD classifier204, the example RPD validator206, the example RPD rectifier208, and/or, more generally, the example RPD calibration module122.

The processor712of the illustrated example includes a local memory713(e.g., a cache). The processor712of the illustrated example is in communication with a main memory including a volatile memory714and a non-volatile memory716via a bus718. The volatile memory714may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or any other type of random access memory device. The non-volatile memory716may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory714,716is controlled by a memory controller.

The processor platform700of the illustrated example also includes an interface circuit720. The interface circuit720may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Bluetooth® interface, a near field communication (NFC) interface, and/or a PCI express interface.

In the illustrated example, one or more input devices722are connected to the interface circuit720. The input device(s)722permit(s) a user to enter data and/or commands into the processor712. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

The processor platform700of the illustrated example also includes one or more mass storage devices728for storing software and/or data. Examples of such mass storage devices728include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives. In some examples, the mass storage device728implements the example panel tuning data database210, and/or the example RPD tuning data database212of the example RPD calibration module122. Additionally or alternatively, in some examples, the memory714implements the example panel tuning data database210, and/or the example RPD timing data database212of the example RPD calibration module122

The machine executable instructions732ofFIGS. 3-6may be stored in the mass storage device728, in the volatile memory714, in the non-volatile memory716, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that example methods, apparatus and articles of manufacture have been disclosed that provide improved functionality for a processor or other computer device analyzing RPD tuning data collected from households. Such RPD tuning data is calibrated such that the RPD tuning data may improve the accuracy of corresponding results and/or improve the subsequent processing of the RPD tuning data.