Five-Map Business Directory Study at Dubai Mall

A tidy spreadsheet can look complete while silently missing a substantial share of the available listings. For a team assessing an area, updating a directory, or checking its own database, that means more manual work and decisions based on an incomplete set of observations.

The usual workflow looks sufficient: open a familiar map, select the maximum zoom, and collect everything visible. A map combines several catalogues and algorithms. Some businesses appear only through a building card, others through category search, and others after markers render. Even a formally completed (terminal) status does not prove that the required data surface was exposed.

We tested this at Dubai Mall with CrawlRover. We first collected a strong, reproducible profile from each of five maps, repeated the attempts, and then searched for already known businesses on the other maps. The main result mattered more commercially than a simple ranking: the combination of sources and methods gave Google 1,059 additional map-native IDs beyond its saved control of 449, and Bing 638 beyond its control of 291. Of those additional IDs, 840 and 504 respectively were strictly inside the original contour.

This is not an estimate of the full Dubai Mall directory or the number of active tenants. It is a measured answer to a practical question: how many verifiable records remain beyond the best saved workflow when signals from other maps are used?

Three findings that change the collection strategy

CrawlRover’s value is a verifiable registry in which each row can be traced back to the map, method, source card, attempt boundary, and reason for manual review. Such an output can be accepted against explicit criteria and reproduced instead of trusted on the strength of a final counter.

This study is especially useful for three types of teams:

• directory and geodata owners who need measurable coverage and provenance;
• territory and network-development analysts who need categories, addresses, and public contacts;
• teams with an existing spreadsheet that need to find gaps, confirm rows across maps, and separate confident matches from disputed ones.

What exactly we compared

The experiment has three distinct levels, and they must not be mixed.

The first is the observed map profile: how many usable listings a particular configuration returns inside a fixed contour. The second is the mechanism’s contribution: which records within one map were first returned by search, render, or building traversal. The third is cross-map verifiability: whether a group already known from one source can be found on another map, and which terminal outcome the search produces.

Across maps, we compare observed output, stability, and the usefulness of fields for a registry. Measuring recall would require an independent exhaustive list of active businesses; none of the maps under test can itself serve as that ground truth.

How the experiment was designed

The contour has 19 vertices. Its SHA-256 is 5f3474ff215276fe4f7b0e94da76e13f13c0cc3bfa4155a224510b254c6d5c31. We used z21 for Yandex and Google, z20 for 2GIS and Apple, and z19 for Bing. Every available arm was run twice, with a 90-minute limit per attempt. The working budget was 24,800 POIs; another 6,200 POIs were protected and could not be used (C-EXT-15).

Arm A contains a map’s area methods without an explicit query. Arm B separately iterates the full supported category set for Yandex, 2GIS, and Google. This separation avoids multiplying expensive rendering or building traversal by dozens of queries. Apple and Bing already include their internal category sweep in the area path, so they do not need a second identical B arm.

We froze raw listings, native IDs, and the method log first. Only then did we build 20 directed source → target routes (C-EXT-06). The same canonical group is searched on one target map only once, even when it is linked to several source rows. This preserves the logic of every direction without spending quota on duplicates.

An attempt is complete when every planned method reaches a terminal state. Limited means that a predefined time or availability boundary was reached. Such a result is still useful for planning, but it cannot be compared with a complete result as if both had equal exposure.

Why the maps should be combined: five different roles

No map in this experiment was best at every property we needed. 2GIS provided scale through a building catalogue, Apple produced well-filled addresses and contacts, Google exposed separate category and render layers, Yandex exposed organization and house catalogues, and Bing added a frontier plus structured fields during directed search. The practical choice is to assign each map a role and control its limits.

2GIS: the foundation of a high-volume registry through the building

The 2GIS area run at z20 completed in 260.1 seconds and saved 1,930 unique native rows. It shared 1,857 IDs with the earlier z17 experiment; 73 appeared and 64 did not repeat, giving a Jaccard score of 0.9313 (C-EXT-01).

The category arm returned 322 rows, but 320 already existed in the area set. The full primary profile grew only to 1,932 native rows (C-EXT-14). For this site, 2GIS gained its scale mainly from the building path; broad search added few new identifiers.

There is an important caveat. In the primary attempt, 1,172 rows were linked exclusively to building_inside, and four more to the card method. Historical method provenance covered 100% of rows, but observations from this specific run covered 62.2%. We can therefore explain the provider and native ID for every row, while the method from this run is known only for the measured share (C-EXT-07).

Yandex: the visible layer can hide an organization catalogue

The primary Yandex area run processed five segments and 1,118 cells but saved no seed listings. Building traversal did not start because there was no source address or organization to feed it. This does not mean the Yandex Dubai Mall catalogue was empty. More precisely, render at z21 did not create an input frontier for the next phase (C-EXT-02).

The category arm returned 197 unique listings and completed 33 of 33 queries. The repeat contained the same 197 IDs, giving a Jaccard score of 1.0000, although one child session ended as partial and the comparison remains descriptive (C-EXT-10, C-EXT-11).

Those 197 are the frozen result of category arm B, not the best possible Yandex output for Dubai Mall. A direct check of the “Inside” link showed 197 unique organization links in the DOM, while the structured SSR catalogue contained 1,233 records with 1,233 unique OIDs. The nearby visible number 550 referred to photos.

The diagnosis found a systemic CrawlRover defect: the parser read the former response.items envelope but not the current results.items.fullPlaces, while card traversal kept the house route and discarded the direct organization-inside route. We added both paths, kept the unproven fallback through ordinary links closed, and repeated the product measurement.

For a fair fix check, we used the same user-defined 20-vertex contour, z17, and the same render+building method set without search. Before the fix, session 348 produced 363 rows. After the fix, session 351 completed in 46.0 seconds and saved 1,605 rows. The result contained three organization containers and eight house targets; at the checkpoint, the Dubai Mall catalogue contributed all 1,233 OIDs. Attribution to that organization container remained on 1,200 rows; 33 more matched richer house listings by native OID and were merged (C-EXT-17).

The correction does not replace the frozen FMX-20260912 table, which used a different 19-vertex contour and z21. The 1,605 count describes the deduplicated output of the selected area, including neighbouring organization and house containers; 1,233 describes the catalogue behind the exact Dubai Mall link. Neither is an independent estimate of active tenants.

Repeat A produced the strongest warning: the primary attempt returned zero and the repeat returned 828, for a Jaccard score of zero (C-EXT-10). The same terminal status does not prove compositional stability. A commercial Yandex collection should combine category search, render, and proven organization/house catalogues, then confirm the result with a repeat that preserves native IDs and provenance routes.

Google: render and categories expose different catalogue layers

The Google area profile at z21 was expensive. In the first fully completed segment, grid search added 13 records, render added another 95, and traversal of 175 buildings added none. The remaining segments did not receive equal exposure, so the full A arm has limited status (C-EXT-03).

The primary category run completed only the first of 32 queries, yet saved 369 listings. The combined A+B profile contains 476 rows: 346 appeared only in B, 107 only in A, and 23 in both arms (C-EXT-14). Using only search or only render would make the client lose another observed part of the registry.

The category repeat saved 368 rows; its Jaccard score against the primary was 0.9759 with descriptive_limited status (C-EXT-10). This is not an estimate for the entire category dictionary: both attempts were limited to the first reached part of the queue.

Apple: a strong base of addresses and contacts

Apple at z20 saved 1,803 unique native rows. Search was observed for 1,730 rows, building_inside for 359, and render for five. Their exclusive contributions were 1,443, 72, and one row respectively. Against the old z17 set, 470 IDs matched, 1,333 appeared, and 791 dropped out; Jaccard was 0.1812 (C-EXT-09).

The fields matter particularly for a client table: name was present for 100% of rows, address and category for 99.9%, phone for 79.8%, and website for 64.5% (C-EXT-14). Apple looks useful as a contact source, but the low overlap with the old set prevents us from calling all of the increase an improvement. The profile is limited and its composition changed substantially.

Bing: discovery through render, followed by detail verification

Bing at z19 saved 224 rows. Render was observed for 212 and search for 24; exclusively they contributed 200 and 12 rows. Against the old z17 set, 83 IDs matched, 141 were added, and six dropped out; Jaccard was 0.3609 (C-EXT-08).

Category and coordinates were present for 100% of rows, but name and address for 25.4%, phone for 10.3%, and website for 10.7% (C-EXT-14). Bing’s role in such a project is to expand the candidate list. Its rows need confirmation on another map or manual review before they form a standalone contact registry.

What changed after we checked the algorithms on live maps

The historical table above remains a snapshot of the primary runs. On the same saved contour, we separately repeated methods after fixing defects, preserving the ID, method, and evidence for each attempt. This repeat changes the practical client choice: it shows which channel actually adds records and where the count is limited by budget or address quality.

Apple C5 at z20 saved 1,785 listings: 811 first arrived through search, 669 through render, and 305 through building catalogues. Render was observed for 730 listings and independently added 37; building independently added 195. All 304 render cells completed, 80 of 81 address seeds were checked with exact queries, and all 1,785 rows received session-level provenance. The original five render listings were caused by an error that tied the visible layer to the viewport. We also refined the geographic boundary: search-only records outside the contour were within 9.66 metres, while the catalogue of a building intersecting the zone contained organizations outside the contour. A registry should mark them as building membership rather than points strictly inside the polygon.

Bing C4 at z19 saved 291 listings: 212 first came from render and 79 from search. The 86-cell render control completed without error. Previously, 24 address checks ended as mismatch without a single fallback query; after the fix the queries ran, but the first batch displaced checks for later addresses. All 13 evidence-backed address seeds now run exact checks before up to 31 bounded recovery queries. Numeric grid labels are no longer treated as a street and house number. Building search added no businesses: Bing did not confirm those addresses with the required precision and distance before the budget ended. For a client, Bing is therefore useful for candidate discovery and independent verification on another map, with unconfirmed addresses explicitly marked.

Google C2 completed the first z21 segment with 110 listings: grid search first found 13, and render another 97. All 110 rows retained the method from this exact attempt; 115 render cells proved coverage without failure, and the final counter showed 110 instead of the erroneous zero in the previous version. Checks of 175 building addresses added no listings. After only 20 cells, the full zone grid was projected to take 288.7 minutes against a 90-minute limit. We therefore completed all methods in the first segment and stopped the remaining four under the predefined rule. This is a complete segment and a limited whole-zone profile; its 110 rows are not presented as the entire Google catalogue for Dubai Mall.

During the same run, the parent task was incorrectly marked stalled after two minutes even though the child segment continued collecting rows and completed. The watchdog did not count child progress for every segmented-run type. We fixed the logic and verified it against the live task store. In the final 5.623.162 build, the parent of a short repeat remained active after 166.8 seconds without its own progress while the child was alive; the group was then stopped normally. This status defect did not lose any of the 110 rows from the completed research segment.

Detailed session counts and source-export hashes are recorded in analysis/apple-bing-google-post-fix-correction.json. They form a separate correction and do not alter the original 1,803/224/130, the five-map union, or the directed-search results. Differences in zoom and method prevent the 1,785/291/110 ratio from being treated as a ranking of map completeness.

A large counter without a repeat can mislead

Repeats were measured by native-ID overlap within the same map and arm. Jaccard for 2GIS A was 0.9674, Apple A 0.9842, Bing A 0.9032, Google A 0.6947, and Yandex A zero. For category arms, 2GIS scored 0.8736, Yandex 1.0000, and Google 0.9759 (C-EXT-10).

A high value does not turn a partial run into a complete profile. It shows the stability of the observed core. A low value does not always mean a poor map: it may come from changing method exposure, dynamic output, or a different input frontier. That is why CrawlRover retains the ID, method, status, and attempt boundary rather than only a final counter.

The most valuable check: what Google and Bing find from other maps’ signals

Area collection answers “what did this map show under this configuration?” Directed search tests a workflow closer to the client’s task: if a business is already known from 2GIS, Apple, or Yandex, can Google or Bing find it, and which target-map fields can it add to the registry?

We did not project percentages from a small sample onto the whole area. For Google and Bing, we ran all six directions—2GIS / Apple / Yandex → Google / Bing—under the FMX-DL-20260915 protocol. The Yandex area repeat expanded the freeze to 6,678 physical requests and 8,622 logical positions. All 6,678 tasks reached terminal: 2,069 were succeeded, 639 links already existed when execution began, 3,187 returned not_found, 753 were sent to a person, and 30 could not be queried without a name.

Repeat A produced 828 Yandex OIDs and category arm B 197; their intersection was 72 and their union 953 OIDs, of which 897 formed organization canonical groups. The 197 count therefore cannot be treated as Yandex’s best result for this area.

The source maps overlap: several sources can confirm the same Google or Bing listing. After deduplication, Google received 1,059 distinct native IDs beyond the saved A∪B control of 449 IDs. Of these, 840 have a Google coordinate strictly inside the contour, 218 are outside, and one has no measured point. Bing received 638 distinct native IDs beyond its C4 control of 291 IDs: 504 inside, 133 outside, and one without a measured point. The internal layer expands the observed Google set from 449 to 1,289 IDs and Bing from 291 to 795. In a commercial project, the outside layer is delivered separately instead of being mixed into the territorial result.

Multiple sources confirmed 536 additional Google IDs and 345 Bing IDs; these can be reviewed before single-source signals. Among the additional Google listings, Google’s own fields provided a name for 1,058 IDs, address for 452, category for 564, phone for 385, and website for 337. For Bing, name, address, and category were present for 637, phone for 582, and website for 504. Google expanded the observed frontier further, while listings found through Bing more often contained structured contacts immediately.

This comparison measures the increase over the tool’s best saved runs. It does not turn the target map into ground truth or estimate the completeness of its catalogue. Not_found means no result from this particular search, not that the organization does not exist in reality.

Why these outcomes are trustworthy

The experiment also found two systemic defects in the Google path. A parent timer closed the worker tab before the internal render/reload cycle completed, and Google’s normal empty-results screen was incorrectly treated as a page that was not ready. In 5.623.169, the tab lives until the collector returns, Stop still interrupts work, and an empty result is accepted only after Google Maps’ own same-origin navigation to /search?q=.... All 26 former technical outcomes were replayed using their original runId/unitId: one produced a match and 25 ended as proven not_found; there were no new retryable outcomes and no access to a closed tab.

For Bing, we separately checked 55 cases where a native link appeared after a negative matcher outcome. In 29 physical tasks, side discovery saw it during the same lookup; 29 cases were repeated with the corrected logic: 24 ended without an erroneous link and five went to a person. Another six links appeared in another task or later, while the full raw origin mechanism remains unknown for 20. Unknown provenance is not counted as success for the current search.

Before the full census, we registered a small sample of 20 missing links in each of 20 directions. All 399 unique physical tasks received a terminal or reconciled identity outcome. The sample showed strong directional asymmetry, but intervals from 19–20 observations were too wide. We therefore used it only to choose which full run to execute, not for marketing extrapolation (C-EXT-06).

Where the map obtained its data

Two different answers are needed. First: which map and method did CrawlRover observe? The provider-native row and acquisition observation answer that. Second: who was the original supplier of a specific field? That can be named only when the listing contains explicit attribution.

For example, Apple publishes a general list of Maps data providers, Google requires per-place and photo attribution to be handled under the Maps JavaScript API policy, Yandex documents attr:Attribution in the YMapsML structure, Microsoft points to Bing credits in its ODbL explanation, and 2GIS describes verification of information submitted by representatives and users in its company-addition help.

A general provider list describes the map’s ecosystem, but it cannot attribute the address or phone in every row. The experiment counted only saved externalProvider, ratingSource, photo host, and other explicit links. If no such field exists, the field’s source remains unknown (C-EXT-13).

This strict filter still exposes concrete relationships. Apple listings explicitly name Foursquare for 183 rows, TripAdvisor for 122, and Zomato for 76. In Bing, four ratings are explicitly linked to Tripadvisor and one to Booking.com; hosts are saved for some individual photos. These figures apply only to explicitly labelled listings and fields, and cannot be extended to the rest of the set (C-EXT-13).

What the client buys: a verifiable registry with acceptance criteria

The value of this project is not the row count alone. The client needs a dataset that supports a decision and explains every uncertainty. The maps therefore receive different roles: 2GIS builds a high-volume building layer, Apple strengthens addresses and public contacts, Google adds categories and render, Yandex exposes organization/house catalogues, and Bing expands and structures the directed-search frontier.

The exact mix depends on the task. A directory of names, categories, and coordinates can accept a broader layer. A registry with phone numbers and websites needs required coverage, permitted sources, and manual-queue size agreed in advance. Regular updates also need a stability criterion between runs.

A pilot should start with one site or a compact area. Before collection, the parties fix the contour, required fields, maps, time and volume limits, merge rules, and stop conditions. Measured speed, field coverage, and review queue from the pilot then support a cost and schedule estimate for a network of sites, a district, or a city.

Four inputs are enough to define the pilot:

1. the target site or polygon;
2. required fields and the purpose of the registry;
3. an existing source table, if it needs checking or enrichment;
4. the acceptable amount of manual review and the required freshness date.

In return, we can prepare a collection design with selected maps and methods, budgets, output format, and measurable acceptance criteria. The first pilot should answer: which configuration produces a registry sufficient for your task, and what does it cost to repeat it reliably?

Limits of the conclusion

The experiment used one contour and one browser session. Four of the five primary profiles had limited exposure, maps change over time, and a canonical match is not independent ground truth (C-EXT-04). We did not verify tenants’ offline status and do not call the result a complete Dubai Mall directory.

The experiment does show what can be verified and repeated: configuration, native IDs, method contribution, field coverage, stability, directed-search outcomes, and the boundary of every attempt. A realistic client delivery is built from this evidence, not from a promise to obtain “everything” with one click.

Ready to try it yourself?

Free plan — compatible store package, basic export, no card required

Related:

→ Cross-map collection→ Find an existing dataset on other maps