Venue detection

Examples of the present disclosure describe systems and methods for venue detection. In aspects, a mobile device comprising a set of sensors may collect and store sensor data from in response to a detected movement event or user interaction data. The sensor data may be used to generate a set of candidate venues corresponding to the location of the mobile device. The candidate venues may be provided to a venue detection system. The venue detection system may process the candidate venues to generate a set of features. The set of features may be applied to, and/or used to generate, one or more probabilistic models. The probabilistic models may generate confidence metrics for each of the candidate venues. In some aspects, the top ‘N’ venues may be selected from the set. The top ‘N’ venues may then be presented to the user and/or used to effect one or more actions.

BACKGROUND

Venue detection systems enable determinations related to mobile device visit patterns. In many cases, the venue detection systems rely almost exclusively on periodic geographic coordinate system data (e.g., latitude, longitude and/or elevation coordinates) to determine the location of a mobile device. For example, the geographic coordinate system data may be used to determine whether a detected stop by a mobile device correlates with a check-in event by the mobile device user at a particular venue. However, the almost exclusive use of geographic coordinate system data may result in inaccurate venue detection.

SUMMARY

Examples of the present disclosure describe systems and methods for venue detection. In aspects, a mobile device comprising a set of sensors may collect and store sensor data from the set of sensors in response to detecting a movement event or user interaction data. The sensor data may be used to generate a set of candidate venues corresponding to the location of the mobile device. The candidate venues may be provided to a venue detection system. The venue detection system may process the candidate venues to generate a set of features. The set of features may be applied to, and/or used to generate, one or more probabilistic models. The probabilistic models may generate confidence metrics for each of the candidate venues. In some aspects, the top ‘N’ venues may be selected from the set. The top ‘N’ venues may then be presented to the user and/or used to effect one or more actions.

DETAILED DESCRIPTION

The present disclosure describe systems and methods for venue detection. In aspects, venue detection maybe described with respect to passive visit detection. Passive visit detection refers to the use of implicit indicia to determine whether a mobile device (or a user thereof) is visiting, or has visited, a particular venue or geographic location. As opposed to active visit detection, which uses explicit user signals (such as user-confirmed venue check-in data), passive visit detection relies on the passive collection of data from various sensors of a mobile device. The analysis of data from various mobile device sensors increases the accuracy and efficiency of visit detections over conventional approaches that only use geographic coordinate system data. Although the venue detection techniques described herein are described with respect to passive visit detection, one of skill in the art will recognize that such techniques may also be applied in other contexts.

In aspects, a mobile device may comprise one or more sensors. Exemplary sensors may include GPS sensors, Wi-Fi sensors, proximity sensors, accelerometers, ambient temperature sensors, gyroscopes, light sensors, magnetometers, hall sensors, acoustic sensors, a touchscreen sensor, etc. The mobile device may monitor data detected by the sensors as the mobile device is used and/or transported by a user. The mobile device may also detect events, such movement events, purchase events, information delivery events, venue check-in events, etc. In some aspects, the detection of an event may cause the sensor data to be collected and processed. Processing the sensor data may include parsing the sensor data to identify one or more venues and/or associated venue data. The identified venues/venue data may be analyzed to identify a set of candidate venues corresponding to events and/or user activity in a geo-fenced area. Geo-fencing, as used herein, may refer to dynamically generating a virtual perimeter around the geographical location of a mobile device. The set of candidate venues may be analyzed to determine a set of features. The set of features may be used to generate one or more feature vectors for each candidate venue. A feature vector, as used herein, may refer to an n-dimensional vector of numerical features that represent one or more objects. The feature vectors may be applied to, or used to generate, one or more data evaluation utilities, such as decision logic, one or more rule sets, or machine learning models. A model, as used herein, may refer to a predictive or statistical language model that may be used to determine a probability distribution over one or more character sequences, classes, objects, result sets or events, and/or to predict a response value from one or more predictors. In examples, a model may be a rule-based model, a machine-learning regressor, a machine-learning classifier, a neural network, or the like.

In aspects, the data evaluation utilities may use feature vectors to generate confidence metrics for a list of candidate venues. The confidence metrics may be indicative of the likelihood a candidate venue corresponds to a particular set of coordinates or an event. In examples, the list of candidate venues may be ranked according to one or more criteria (such as confidence metrics), and presented via a user interface. In some aspects, the list of candidate venues may be calibrated to increase the accuracy and/or confidence of the candidate venue selections, or reduce the number of candidate venue selections. The calibration may include the use of heuristics and one or more threshold value comparisons. In examples, the calibration may result in a selection of the top ‘N’ venues from the list of candidate venues. One or more of the top ‘N’ venues may be presented to a user via a display interface. The display interface may provide for receiving one or more user selections. The user selection may be used to further calibrate the list of top ‘N’ venues.

Accordingly, the present disclosure provides a plurality of technical benefits including but not limited to: detecting passive visit events; enabling venue-based geo-fencing; enabling the collection venue/location data using various mobile device sensors; enabling the collection venue data and user data from one or more data stores, generating venue-based feature vectors; applying machine learning techniques to determine probabilities for a list of venues; refining venue selection using user-based denial information; improving the measurement of relative visit totals between venues; calibrating venue lists to remove low probability venues; evaluating the accuracy of probabilistic models using objective functions; and improved efficiency and quality for applications/services utilizing examples of the present disclosure, among other examples.

FIG.1illustrates an overview of an example system for venue detection as described herein. Example system100presented is a combination of interdependent components that interact to form an integrated whole for venue detection systems. Components of the systems may be hardware components or software implemented on and/or executed by hardware components of the systems. In examples, system100may include any of hardware components (e.g., used to execute/run operating system (OS)), and software components (e.g., applications, application programming interfaces (APIs), modules, virtual machines, runtime libraries, etc.) running on hardware. In one example, an example system100may provide an environment for software components to run, obey constraints set for operating, and utilize resources or facilities of the system100, where components may be software (e.g., application, program, module, etc.) running on one or more processing devices. For instance, software (e.g., applications, operational instructions, modules, etc.) may be run on a processing device such as a computer, mobile device (e.g., smartphone/phone, tablet, laptop, personal digital assistant (PDA), etc.) and/or any other electronic devices. As an example of a processing device operating environment, refer to the example operating environments depicted inFIG.4. In other examples, the components of systems disclosed herein may be spread across multiple devices. For instance, input may be entered on a client device and information may be processed or accessed from other devices in a network, such as one or more server devices.

As one example, the system100comprises client device102, distributed network104, venue analysis system106and a storage108. One of skill in the art will appreciate that the scale of systems such as system100may vary and may include more or fewer components than those described inFIG.1. In some examples, interfacing between components of the system100may occur remotely, for example, where components of system100may be spread across one or more devices of a distributed network.

Client device102may be configured to collect sensor data related to one or more venues. In aspects, client device102may comprise, or have access to, one or more sensors. The sensors may be operable to detect and/or generate sensor data for client device102, such as GPS coordinates and geolocation data, positional data (such as horizontal and/or vertical accuracy), Wi-Fi information, OS information and settings, hardware information, signal strengths, accelerometer data, time information, etc. Client device102may collect and process the sensor data. In some aspects, client device102may collect and/or process sensor data in response to detecting an event or the satisfaction of one or more criteria. For instance, sensor data may be collected in response to a detected stop by client device102. In examples, detecting a stop may include the use of one or more machine learning techniques or algorithms, such as expectation-maximization (EM) algorithms, Hidden Markov Models (HMMs), Viterbi algorithms, forward-backward algorithms, fixed-lag smoothing algorithms, Baum-Welch algorithms, etc. Collecting the sensor data may include aggregating data from various sensors, organizing the data by one or more criteria, and/or storing the sensor data in a data store (not shown) accessible to client device102. The collected sensor data may be provided to (or be accessible by) an analysis utility, such as venue analysis system106, via distributed network104.

Venue analysis system106may be configured to produce one or more venue lists. In aspects, venue analysis system106may have access to one or more sets of sensor data. Venue analysis system106may process the sensor data to identify a candidate set of venues. Processing the sensor data may comprise parsing the sensor data to identify one or more locations of client device102. The one or more locations of client device102may be applied to a classification algorithm, such as a k-nearest neighbor algorithm, to fetch a candidate set of venues. The k-nearest neighbor algorithm, as used herein, may refer to a classification (or regression) technique wherein an object is classified by a majority vote of its neighbors, with the object being assigned to the class most common among its k nearest neighbors. In examples, the candidate set of venues generated using the classification algorithm may comprise venues near to, or within a specific proximity of, a location reported for client device102.

Venue analysis system106may be further configured to generate one or more feature vectors. In aspects, venue analysis system106may generate a feature vector for one or more venues in a candidate set of venues. Generating a feature vector may comprise combining sensor data associated with a venue with information from one or more knowledge sources. In examples, the information may include historical and/or predicted venue and user data. Venue analysis system106may evaluate the feature vectors using one or more probabilistic data models or predictive algorithms, such as a decision tree. A non-exhaustive list of decision tree learning techniques include classification trees, regression trees, boosted trees, bootstrap aggregated trees, rotation forests. In examples, evaluating the feature vectors may include the use of one or more gradient boosting techniques. Gradient boosting, as used herein, may refer to one or more machine learning techniques for classification and regression, which produces a prediction model in the form of an ensemble of weak prediction models. The gradient boosting may incorporate factors such as venue age, venue popularity, proximity to other venues, historical accuracy of venue choices/selections, previous venue visits, implicit/explicit user feedback, etc. The evaluation of the feature vectors may result in the calculation of scores or probabilities for the venues in the candidate set of venues. The scores/probabilities may be assigned to feature vector (or features thereof), or assigned to the corresponding venues in the candidate set of venues. Such scores/probabilities may represent the likelihood that a venue corresponds to location data reported by client device102. The candidate set of venues, feature vectors and associated feature data, and/or scores/probabilities may be stored in a data store, such as storage(s)108.

Venue analysis system106may be further configured to calibrate the candidate set of venues. In aspects, calibrating the candidate set of venues may comprise evaluating the scores/probabilities for each candidate venue against a threshold value. Venues having scores/probabilities below the threshold value may be removed from the candidate set of venues or diminished in some manner. In examples, determining the threshold value may comprise evaluating one or more sets of heuristics against the candidate set of venues to determine a set of venue visit distribution. The venue visit distribution may comprise one or more of the venues in the candidate set of venues and/or one or more venues associated with a reported location of client device102. Venue analysis system106may compare the set of venue visit distributions (or an aggregated venue visit distribution) to a set of labeled and/or unlabeled training data. Based on the comparison, a threshold value identifying venues with a low likelihood of corresponding to location data reported by client device102is determined. In some aspects, calibrating the candidate set of venues may further comprise determining a list of top ‘N’ venues. The list of top ‘N’ venues may represent the venue candidates most likely to correspond to the location of a mobile device. In examples, determining the list of top ‘N’ venues may include evaluating the scores/probabilities for each candidate venue against a threshold value. For instance, the top three (e.g., ‘N’=3) venues having the highest scores/probabilities may be selected. In at least one example, the determining the list of top ‘N’ venues may additionally include receiving user-selection data. For instance, a set of venues may be presented to a user via an interface component accessible to venue analysis system106. Venue analysis system106may receive a selection of one or more venues in the set of venues. The selected venue(s) may represent the top ‘N’ venue(s). Alternately, the selected venue(s) may represent venues to be removed from the list of top ‘N’ venues, or an adjustment to the ranking of the list of top ‘N’ venues. The list of top ‘N’ venues may be stored in storage(s)108and/or presented via a display interface.

Venue analysis system106may be further configured to evaluate the accuracy of one or more probabilistic models. In aspects, venue analysis system106may have access to a set of training data. The training data may comprise, for example, previously received input data (e.g., sensor data, feature vectors, corresponding feature data, etc.) and/or determined or selected venue outputs. Venue analysis system106may apply the input data to one or more probabilistic models. The output of each probabilistic model may be provided to an objective function used to determine the accuracy or effectiveness of the one or more probabilistic models. In examples, the objective function may be defined in myriad ways using various parameters. The objective function may calculate a score representing how closely the output of a probabilistic model matches the corresponding output in the training data. Based on the calculated scores, venue analysis system106may rank the one or more probabilistic models. In one example, the highest ranking probabilistic model may be selected for use when a set of feature vectors is received.

FIG.2illustrates an overview of an example input processing device200for venue detection, as described herein. The venue detection techniques implemented by input processing device200may comprise the venue detection techniques and content described inFIG.1. In alternative examples, a single system (comprising one or more components such as processor and/or memory) may perform processing described in systems100and200, respectively.

With respect toFIG.2, input processing unit200may comprise retrieval engine202, feature engine204, probabilistic model engine206, user interface208and calibration engine210. Retrieval engine202may be configured to generate one or more feature sets for a set of sensor data. In aspects, retrieval engine202may have access to a set of sensor data collected from a mobile device. The sensor data may represent input from a user or physical environment associated with the mobile device. The sensor data may comprise input collected from various sensors of (or accessible to) the mobile device. In some aspects, retrieval engine202may process the sensor data in response to detecting an event or the satisfaction of one or more criteria. For instance, the retrieval engine202may receive an indication or otherwise detect that a mobile device has stopped movement. Detecting a stop may comprise sampling sensor data over time, featurizing the sensor data, and applying a stop detection model to the featurized data to determine whether a mobile device has stopped moving. Processing the sensor data may include parsing the sensor data for one or more individual sensors or sensor types to identify venues and/or associated venue data. In aspects, venue data may be used to retrieve a set of candidate venues. For example, the venue data may be applied to a classification algorithm, such as a k-nearest neighbor algorithm. The classification algorithm may determine a list of candidate venues that is within a specific proximity or density distribution of a location reported for a mobile device. In another example, a set of geographical coordinates (or other geolocation identifier) may be provided to a venue determination utility, such as a geographical mapping service. In such an example, the number of venues may depend on the size of the display area presenting the venues.

Feature engine204may be configured to generate feature vectors for the list of candidate venues. In aspects, feature engine204may have access to the list of candidate venues. Feature engine204may correlate each candidate venue to information associated with the candidate venue. For instance, a candidate venue may be correlated to popular nearby venues, similarly named or themed venues, or otherwise related venues. Venue data for the candidate venues and correlated venue data may be identified and used to generate a feature vector for each identified venue. In one example, generating a feature vector may comprise organizing similar features or feature categories, normalizing corresponding feature values, and adding the normalized feature values to a feature vector. In aspects, the feature vector may represent how well the sensor data for a venue matches historical data for that venue. As an example, a mobile device may perform a Wi-Fi scan during a detected stop. The Wi-Fi scan data may be compared to the Wi-Fi scan data of each candidate venue to generate a feature score. The feature score may represent how well the Wi-Fi data matches each of the candidate venues.

Probabilistic model engine206may be configured to generate and/or train one or more models. In aspects, probabilistic model engine206may have access to one or more feature vectors. Probabilistic model engine206may apply one or more gradient boosting techniques to generate a probabilistic model comprising an ensemble of decision trees. The gradient boosting techniques may incorporate factors such as venue age, venue popularity, proximity to other venues, historical accuracy of venue choices/selections, previous venue visits, etc. In at least one example, gradient boosting techniques may also incorporate explicit user feedback. For instance, a result set comprising explicit user confirmations or denials of venue location may also be used to generate probabilistic model206. In some aspects, a probabilistic model may have access to one or more feature vectors. The feature vectors may comprise feature data and/or feature scores for a candidate set of venues. The probabilistic model may receive the feature vectors as input, and may output a confidence score or probability for each venue in a candidate set of venues. The confidence score/probability may be indicative of the likelihood a venue corresponds to a particular set of coordinates or an event. In at least one example, a probabilistic model may generate a probabilistic distribution for venues in the candidate set of venues. The probabilistic distribution may assign a probability or confidence score to each venue in the venue list using, for example, a probability density function.

In aspects, probabilistic model engine206may be further configured to evaluate the accuracy of one or more probabilistic models. Probabilistic model engine206may have access to a set of training data comprising, for example, previously received input data (e.g., sensor data, feature vectors, feature scores, etc.), explicit user feedback, labeled venue outputs, venue determination analyses, etc. Probabilistic model engine206may apply the input data to one or more probabilistic models. The probabilistic model(s) may have been previously generated, recently generated, or may be generated as part of the evaluation by probabilistic model engine206. The output of each probabilistic model may be provided to an objective function used to determine the accuracy or effectiveness of the one or more probabilistic models. In examples, the objective function may define the criteria and/or parameters to be evaluated. The objective function may define the number and type of probabilistic model(s) to be evaluated. In aspects, the objective function may compare the output of each probabilistic model with the output in the training data. Based on the comparison, the objective function may calculate a score representing how closely the probabilistic model output matches the training data output. The highest ranking probabilistic model(s) may be recorded and selected for use when feature vectors are subsequently received.

User interface208may be configured to present a venue list. In aspects, user interface208may enable a user to view, navigate and manipulate a venue list and/or data associated therewith. In examples, user interface208may present the venue list as a textual list, a graphical object (e.g., a geographical map or similar visualization), a report, etc. User interface208may also provide access to settings or configurations for interacting with the venue list. User interface208may be further configured to provide training data to probabilistic model engine206. In aspects, user interface208provide access to one or more sets of training data. The training data may be located locally on input processing unit200or on a remote device. In examples, the training data may be labeled or unlabeled input signals. Labeled data may comprise sensor values and corresponding labeled events and venues. The training data may be applied to a probabilistic model to train the probabilistic model to produce a more accurate or relevant venue list. In examples, producing a more accurate or relevant venue list may comprise determining the most relevant or indicative parameter(s)/feature(s) in the set of labeled data. Such a determination may include applying a weight to the parameter(s)/feature(s) and/or removing parameter(s)/feature(s) from the venue list analysis.

Calibration engine210may be configured to refine a venue list. In aspects, calibration engine210may have access to one or more venue lists. Calibration engine210may apply one or more processing techniques to a venue list to increase the accuracy and/or confidence of the venue selections, or reduce the number of venue selections. For example, calibration engine210may compare one or more probabilities or confidence scores associated with a candidate set of venues to a threshold value. The threshold value may represent a minimal probability/confidence score for a venue candidate to be included in the candidate set of venues. As a particular example, venues having a probability/confidence score below 1% may be removed from a candidate set of venues. In aspects, a threshold value may be determined or selected by applying, for example, a rule set, a set of heuristics, or other analysis techniques to a candidate set of venues to generate a venue visit distribution. The venue visit distribution may identify the frequency that one or more venues has reported a visit for a period of time. In some aspects, calibration engine210may compare the venue visit distributions to a set training data. The training data may comprise labeled or unlabeled venue data, such as venues, check-in information, user data and signals, probabilities/confidence scores, etc. The training data may be used to evaluate venue probabilities/confidence scores and/or visit distributions. Based on the evaluation, a threshold value may be selected. The threshold value may be indicative of a probability/confidence score below which venues have a low likelihood of corresponding to location data reported by a mobile device. The threshold value may be used to determine a list of top ‘N’ venues. The list of top ‘N’ venues may represent the venue candidates most likely to correspond to the location of the mobile device. In examples, the top ‘N’ venues may be determined by selecting a specific number of venue results, selecting venue results above a specific probability threshold, etc.

Having described various systems that may be employed by the aspects disclosed herein, this disclosure will now describe one or more methods that may be performed by various aspects of the disclosure. In aspects, method300may be executed by an example system, such as system100ofFIG.1. In examples, method300may be executed on a device, such as input processing unit200, comprising at least one processor configured to store and execute operations, programs or instructions. However, method300is not limited to such examples. In other examples, method300may be performed on an application or service for performing venue detection. In at least one example, method300may be executed (e.g., computer-implemented operations) by one or more components of a distributed network, such as a web service/distributed network service (e.g. cloud service).

FIG.3illustrates an example method300for venue detection, as described herein. Example method300begins at operation302, where sensor data may be received. In aspects, sensor data from one or more sensors of (or associated with) a mobile device, such as client device102, may be monitored or collected. The sensor data may comprise information associated with GPS coordinates and geolocation data, positional data (such as horizontal accuracy data, vertical accuracy data, etc.), Wi-Fi data, over the air (OTA) data (e.g., Bluetooth data, near field communication (NFC) data, etc.), OS information and settings, hardware/software information, signal strength data, movement information (e.g., acceleration, time and directional data), etc. The sensor data may be collected continuously, intermittently, upon request, or upon the satisfaction of one or more criteria, such as a detected stop, an appreciable change in movement velocity and/or direction, a check-in, a purchase event, the receipt of a message by the mobile device, or the like.

In aspects, the sensor data may be monitored to identify relevant data points, time frames, movement events and/or venue information. For example, sensor data may be monitored as a mobile device is moving along a storefront. A stop detection utility may monitor the sensor data received by the mobile device. For a first period of time, the stop detection utility may analyze sensor data comprising a Wi-Fi signal (e.g., detection of “Store A” Wi-Fi network) over a successive period of ten polling cycles (e.g., a 10 minute time period). The stop detection utility may determine that, because the Wi-Fi signal was detected during each of the ten polling cycles, the mobile device was continually proximate to Store A. Accordingly, the stop detection utility may determine a visit state of “Visiting” for Store A. In response to the “Visiting” visit state, the stop detection utility may collect and store the sensor data for the first period. For a second period of time, the stop detection utility may analyze sensor data comprising multiple Wi-Fi signals (e.g., detection of “Store A” and “Store B” Wi-Fi networks) and corresponding signal strengths. Based on the sensor data, the stop detection utility may determine the mobile device was proximate to Store B, but the mobile device did not actually enter the store. For instance, Wi-Fi network device for Store B may be 55 feet inside the storefront door. A device may record the signal strength of the “Store B” Wi-Fi network as −80 dBm at a radius of 55 feet from the Wi-Fi network device, −70 dBm at a radius of 25 feet from the Wi-Fi network device and −50 dBm at a radius of 5 feet from the Wi-Fi network device. Over the course of the second period of time, the mobile device may have recorded signal strengths between −85 and −80, indicating the mobile device did not enter Store B. Accordingly, the stop detection utility may determine a visit state of “Traveling” or “Stopped” for Store B. In response to the “Traveling” visit state, the stop detection utility may not collect and store the sensor data for the second period. For a third period of time, the stop detection utility may use accelerometer data, one or more electronic messages (e.g., a text or email advertisement, coupon, event schedule, receipt, etc.) and GPS coordinates over a polling period to determine that the mobile device was proximate to Store C. For example, the stop detection utility may identify that the mobile device was travelling away from Store C at 3.5 mph at 12:05 pm; the mobile device received an email advertisement for Store C at 12:06 pm; the mobile device altered its course to travel toward Store C at 12:08 pm; the mobile device was travelling toward from Store C at 3.5 mph between 12:08 and 12:15; the Store C Wi-Fi “Store C” was detected at 12:15 pm; and the mobile device was travelling at between 0.1 and 1.8 mph (e.g., browsing speeds) between 12:15 μm and 12:45 pm. Based on this data, the stop detection utility may infer a visit state of “Visiting” for Store C. In response to the “Visiting” visit state, the stop detection utility may collect and store the sensor data for the third period.

At operation304, a set of candidate venues may be generated. In aspects, the sensor data of a mobile device may be accessible to a venue retrieval utility, such as retrieval engine202. The venue retrieval utility may parse the sensor data to identify venues and/or associated venue data. The venue data may be applied to a model or algorithm usable for venue-identification. For example, the venue data may be applied to a classification algorithm, such as a k-nearest neighbor algorithm. The classification algorithm may use the venue data to identify candidate venues that are within a specific proximity or density distribution of a location reported for a mobile device. For instance, the classification algorithm may utilize a geographical mapping service to identify every venue within 500 feet of a set of geographical coordinates. In at least one example, the classification algorithm may further incorporate factors such as venue popularity, venue visit recency, venue ratings, sales data (regional, seasonal, etc.), user preference data, etc. For instance, the classification algorithm may use a knowledge source to retrieve popularity information for one or more identified venues. The venues may then be sorted according to venue popularity and the most relevant/popular venues (for example, the 100 most popular venues) may be selected.

At operation306, candidate venue data may be featurized to generate one or more feature sets. In aspects, data set of candidate venues may be provided to, or accessible by, a featurization component, such as feature engine204. The featurization component may identify sensor data and/or venue data corresponding to one or more of the candidate venues. The sensor/venue data may be evaluated to generate a set of features indicative of characteristics (and corresponding values) associated with the candidate venues. For example, the featurization component may receive as input the following sensor data for one or more venues:

The featurization component may generate a set of scores corresponding to one or more elements or features in the sensor data. For example, the featurization component may use the above sensor data and/or historical data related to venues represented by the sensor data to generate one or more location-based scores. In a particular example, the location-based scores may represent evaluations of various Wi-Fi networks. For instance, the following location-based scores may be generated for the above sensor data:

The sensor data and the set of scores may be used to generate and/or populate one or more feature vectors. For instance, the featurization component may organize a set of features and values into one or more types or categories, such as location, device, time, movement, etc. The organized features and feature values may be scaled and/or normalized. The normalized features and/or feature values may then be added to a feature vector. Feature vectors may be provided to, or made accessible to, one or more data analysis utilities and/or data stores.

At operation308, one or more metrics may be generated for a set of candidate venues. In aspects, feature vectors may be accessible to a data analysis utility, such as probabilistic model engine206. The feature vectors may comprise feature data and/or feature scores for a candidate set of venues. The data analysis utility may use one or more gradient boosting techniques to generate a probabilistic model. The probabilistic model may evaluate the feature vectors to generate one or more probabilities or confidence scores for each venue in a candidate set of venues. The probabilities/confidence scores may be indicative of the likelihood a venue corresponds to a particular set of coordinates, or the likelihood a venue is being visited. In examples, generating the probability/confidence score may include applying a scoring algorithm or machine learning techniques to the feature scores in the feature vector corresponding to each candidate venue. In a particular example, the scoring algorithm may include summing the feature scores of each candidate venue. In another example, the scoring algorithm may include applying a set of weights or multipliers to one or more feature scores. In aspects, candidate venues may be organized or ranked according to, for example, the probability/confidence scores generated by the probabilistic model.

At operation310, a venue list may be calibrated to increase the accuracy of the venue list. In aspects, a calibration component, such as calibration engine210, may access a venue list. The calibration component may apply one or more processing techniques to the venue list to increase the accuracy and/or confidence metrics of the venue selections, or reduce the number of venue selections. For example, the calibration component may compare one or more probabilities or confidence scores associated with candidate venues to a threshold confidence value. The threshold confidence value may represent a probability/confidence score that must be exceeded for a venue candidate to be included in a venue list. In examples, a threshold value may be determined or selected by applying, for example, one or more sets of heuristics to candidate venues. The heuristics may be used to generate a venue visit distribution for the candidate venues. The venue visit distribution may identify the frequency that a venue visit has been explicitly or implicitly reported for a period of time. In some aspects, the venue visit distribution for the venue candidates may be compared to the venue visit distribution for the training data. Based on the evaluation, a threshold value may be selected. Candidate venues below the threshold value may be removed from the list of candidate venues or noticeably diminished. For instance, candidate venues having a confidence score below 1% may be removed from the list of candidate venues, and candidate venues having a confidence score below 50% may be marked accordingly. The marking may include modifying the color, font or transparency of the candidate venues, or adding an indicator to the candidate venues.

In aspects, after a venue list has been calibrated (or as part of the calibration process), the calibration component may generate a list of the top ‘N’ venues. The list of the top ‘N’ venues may comprise one or more candidate venues from the venue list. The list of top ‘N’ venues may represent the venue candidates most likely to correspond to the location of a mobile device or to a visit event. In examples, the top ‘N’ venues may be determined by selecting a specific number of venue results, selecting venue results above a specific probability threshold, evaluating user selection data, etc. In some aspects, the list of top ‘N’ venues may be ranked and or organized according to one or more criteria. For example, a venue list may comprise “Store A” having a preliminary confidence score of 55%, “Store B” having a preliminary confidence score of 40%, and “Store C” having a preliminary confidence score of 5%. After this venue list has been refined, the refined venue list may comprise “Store A” having a final confidence score of 25%, “Store B” having a final confidence score of 75% and “Store C” having a final confidence score of 0%. The calibration component may calibrate the refined venue list such that the venues are listed in the order Store A, Store B, and Store C. In at least one example, the refined venue list may be ranked according to the final confidence score, such that Store B is the top-ranked venue and Store A is the second-ranked venue. A setting specifying that the top 2 venues are to be listed in the refined venue list may cause the Store C venue to be removed from the refined venue list. In some aspects, the refined venue list may be presented to a user via an interface, such as user interface208.

FIG.4illustrates an exemplary suitable operating environment for the venue detection system described inFIG.1. In its most basic configuration, operating environment400typically includes at least one processing unit402and memory404. Depending on the exact configuration and type of computing device, memory404(storing, instructions to perform the venue detection embodiments disclosed herein) may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of the two. This most basic configuration is illustrated inFIG.4by dashed line406. Further, environment400may also include storage devices (removable,408, and/or non-removable,410) including, but not limited to, magnetic or optical disks or tape. Similarly, environment400may also have input device(s)414such as keyboard, mouse, pen, voice input, etc. and/or output device(s)416such as a display, speakers, printer, etc. Also included in the environment may be one or more communication connections,412, such as LAN, WAN, point to point, etc. In embodiments, the connections may be operable to facility point-to-point communications, connection-oriented communications, connectionless communications, etc.

The embodiments described herein may be employed using software, hardware, or a combination of software and hardware to implement and perform the systems and methods disclosed herein. Although specific devices have been recited throughout the disclosure as performing specific functions, one of skill in the art will appreciate that these devices are provided for illustrative purposes, and other devices may be employed to perform the functionality disclosed herein without departing from the scope of the disclosure.

This disclosure describes some embodiments of the present technology with reference to the accompanying drawings, in which only some of the possible embodiments were shown. Other aspects may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments were provided so that this disclosure was thorough and complete and fully conveyed the scope of the possible embodiments to those skilled in the art.

Although specific embodiments are described herein, the scope of the technology is not limited to those specific embodiments. One skilled in the art will recognize other embodiments or improvements that are within the scope and spirit of the present technology. Therefore, the specific structure, acts, or media are disclosed only as illustrative embodiments. The scope of the technology is defined by the following claims and any equivalents therein.