# DLD September residential sales: null-field audit, 2 October 2026

> A 2 October audit of 11,134 DLD residential Sales rows, showing literal null and non-null counts across 21 returned fields.

Source: https://withlida.com/insights/dubai-dld-september-residential-sales-null-audit-2026

---

:::intro
At 04:24:57 Gulf Standard Time (GST) on 2 October 2026, the Dubai Land Department's exact 1 to 30 September residential Sales query returned **11,134 rows**. Across 21 declared English-facing analysis fields, `MASTER_PROJECT_EN` was null in **11,091 rows, or 99.61%**, while 11 declared fields including transaction date, area and value had no literal nulls.
:::

:::summary
- The most complete fields in this declared set were transaction number, date, transaction and usage labels, registration label, freehold label, area, property type, transaction value and the two returned area measures. Each had 0 literal nulls in 11,134 rows.
- `MASTER_PROJECT_EN` had the highest null share: 11,091 nulls and 43 non-nulls, or 99.61% null.
- `PARCEL_ID`, `NEAREST_MALL_EN` and `NEAREST_METRO_EN` were each null in more than half of the returned rows.
- Presence is not the same as uniqueness or analytical fitness. The 11,134 non-null transaction-number values contained 11,131 distinct strings, while the non-null `PROPERTY_ID` field was 0 in every row.
- A null means only that the exact returned key has a JSON null value in that row. It does not establish zero, no nearby service, no project or no record elsewhere in DLD's systems.
:::

## Which returned fields carry nulls?

Ten of the 21 declared fields had at least one literal null; 11 had none. The table is ordered by null share and uses the saved response to the [Dubai Land Department Real Estate Data query](https://dubailand.gov.ae/en/open-data/real-estate-data/), accessed 2 October 2026. Dubai Land Department, or DLD, is the official property registry authority whose public interface issued the response.

| Returned field | What this audit treats it as | Literal nulls | Non-nulls | Null share |
| --- | --- | ---: | ---: | ---: |
| `MASTER_PROJECT_EN` | English master-project label | 11,091 | 43 | 99.61% |
| `PARCEL_ID` | Returned parcel identifier | 6,914 | 4,220 | 62.10% |
| `NEAREST_MALL_EN` | English nearest-mall label | 6,283 | 4,851 | 56.43% |
| `NEAREST_METRO_EN` | English nearest-metro label | 6,182 | 4,952 | 55.52% |
| `NEAREST_LANDMARK_EN` | English nearest-landmark label | 4,631 | 6,503 | 41.59% |
| `PARKING` | Returned parking string | 1,583 | 9,551 | 14.22% |
| `PROJECT_EN` | English project label | 790 | 10,344 | 7.10% |
| `ROOMS_EN` | English room label | 609 | 10,525 | 5.47% |
| `IS_FREE_HOLD` | Numeric freehold field | 143 | 10,991 | 1.28% |
| `PROP_SB_TYPE_EN` | English property-subtype label | 71 | 11,063 | 0.64% |
| `ACTUAL_AREA` | Returned property-area value | 0 | 11,134 | 0.00% |
| `AREA_EN` | English DLD area label | 0 | 11,134 | 0.00% |
| `GROUP_EN` | English transaction-group label | 0 | 11,134 | 0.00% |
| `INSTANCE_DATE` | Returned transaction timestamp | 0 | 11,134 | 0.00% |
| `IS_FREE_HOLD_EN` | English freehold label | 0 | 11,134 | 0.00% |
| `IS_OFFPLAN_EN` | English registration label | 0 | 11,134 | 0.00% |
| `PROCEDURE_AREA` | Returned transaction-area value | 0 | 11,134 | 0.00% |
| `PROP_TYPE_EN` | English property-type label | 0 | 11,134 | 0.00% |
| `TRANSACTION_NUMBER` | Returned transaction-number string | 0 | 11,134 | 0.00% |
| `TRANS_VALUE` | Returned transaction value | 0 | 11,134 | 0.00% |
| `USAGE_EN` | English usage label | 0 | 11,134 | 0.00% |

Every row contributes once to each line. For each field, nulls plus non-nulls equals 11,134. All 21 keys were present in every row, and none used an empty string. The counts come from the saved official transaction response captured 2 October 2026; the response endpoint accepts the interface's POST request but is not a resolving reader page.

::figure{src="images/blog/dubai-dld-september-residential-sales-null-audit-2026/inline-1.png" alt="Five-field ladder of DLD September residential-sales null shares" caption="Selected null shares from the 2 October capture, ordered from 99.61% to 7.10%."}

The useful read is not that one column is good and another is bad. It is that each comparison needs a declared denominator. A project-name analysis can use the 10,344 non-null `PROJECT_EN` rows if it clearly excludes the 790 nulls. A master-project analysis has only 43 non-null rows in this capture, so any result based on that field describes a much narrower returned subset.

## Which fields are populated enough for comparison?

The 11 zero-null fields are the cleanest starting set for a population-wide comparison, but a zero-null count is only a completeness test. It does not prove uniqueness, stable meaning or a useful identifier.

`TRANSACTION_NUMBER` illustrates the distinction. All 11,134 rows have a value, but the response contains 11,131 distinct transaction-number strings. The row population and the distinct transaction-number population are therefore different measures. The [30 September capture methodology](/insights/dubai-residential-sales-september-filter-capture-2026) makes the same row-versus-identifier distinction.

`PROPERTY_ID` provides the opposite edge case. It is one of the 50 returned keys and is never null, yet its numeric value is 0 in all 11,134 rows. This audit records that fact without treating 0 as a usable property identifier.

Field identity also matters. The numeric `IS_FREE_HOLD` field contains 143 nulls, 375 zeroes and 10,616 ones. The separate English label `IS_FREE_HOLD_EN` has no nulls and returns 10,616 `Free Hold` labels and 518 `Non Free Hold` labels. Those are different returned columns. A comparison should declare which one it uses rather than transferring the completeness of the label to the numeric field.

## What changed from the 30 September capture?

The matched historical comparison is narrow: the parsed query values are identical, and both responses expose the same 50 field names. Under those conditions, the 30 September response had 10,770 rows and the 2 October response had 11,134, a difference of 364 rows or 3.38%. This compares two capture-level populations. It does not claim that a particular record was revised.

| Matched field | 30 Sep nulls | 30 Sep share | 2 Oct nulls | 2 Oct share |
| --- | ---: | ---: | ---: | ---: |
| `MASTER_PROJECT_EN` | 10,727 | 99.60% | 11,091 | 99.61% |
| `PARCEL_ID` | 6,703 | 62.24% | 6,914 | 62.10% |
| `NEAREST_METRO_EN` | 5,991 | 55.63% | 6,182 | 55.52% |
| `PARKING` | 1,518 | 14.09% | 1,583 | 14.22% |
| `PROJECT_EN` | 760 | 7.06% | 790 | 7.10% |

The null count rises when the population grows, so the share is the more useful capture-level comparison. Even then, a changed share does not identify which rows were added, removed or altered. A row-level revision test would need a stable matching rule and a separate comparison of the matched records.

## What does a null prove?

A null proves one thing in this audit: the exact key exists in the returned row and its JSON value is `null`. It does not mean numeric zero, an empty string or a missing key. The code checks those states separately.

The limit is equally important. A null `NEAREST_METRO_EN` does not prove that no Metro station is nearby. A null `PROJECT_EN` does not prove that the property has no project relationship. A null `MASTER_PROJECT_EN` does not prove that DLD has no master-project record on another surface. The [DLD data-source map](/insights/dubai-dld-real-estate-data-sources-2026) shows why transaction, project, unit and other official records must keep their own identities.

This is also why the audit does not impute values. Filling a null from a shared name, nearby row or another service would create a derived field. That may be a separate research method, but it would no longer be a count of the exact DLD response.

## Method and reproducibility record

The fresh request repeated the declared September query on 2 October 2026. DLD's public interface exposes Sales and Residential filters, and its official [publicData.js page script](https://dubailand.gov.ae/scripts/publicData.js?v=10) declares the transaction parameter names used below. The returned rows themselves all carry `GROUP_EN: Sales` and `USAGE_EN: Residential`.

| Query key | Saved value |
| --- | --- |
| `P_FROM_DATE` | `09/01/2026` |
| `P_TO_DATE` | `09/30/2026` |
| `P_GROUP_ID` | `1` |
| `P_USAGE_ID` | `1` |
| `P_IS_OFFPLAN` | empty, all registration labels |
| `P_IS_FREE_HOLD` | empty, all freehold labels |
| `P_AREA_ID` | empty, all areas |
| `P_PROP_TYPE_ID` | empty, all property types |
| `P_TAKE` | `15000` |
| `P_SKIP` | `0` |
| `P_SORT` | `INSTANCE_DATE_DESC` |

::figure{src="images/blog/dubai-dld-september-residential-sales-null-audit-2026/inline-2.png" alt="Three-stage path from saved DLD query to raw JSON and field audit" caption="The query, raw response and recomputed field audit remain separate saved artefacts."}

:::aside{title="Capture record, 2 October 2026"}
The official response timestamp is 04:24:57 GST. The raw response is 14,208,491 bytes with SHA-256 `b1b7542b44c88432c30c5a976bb37ec22edf1738151de2a67d454f93e5754864`. The query-file SHA-256 is `e927e3da4d94506bc528c5a05043264ce7c77c503a32123d6987484aa968a7ff`. The response repeats a total of 11,134, and row numbers form the complete sequence from 1 to 11,134. The public page exposes no formal finalisation boundary, so this is a dated extraction, not a final September total.
:::

The saved program counts literal nulls and non-nulls for all 50 returned keys, then checks every sum against the row population. It also checks for missing keys, blank strings, repeated totals, the row-number sequence, query equality and field-name equality. Every reconciliation passed on the 2 October files.

## FAQ, checked 2 October 2026

::::faq
:::faq-item{q="How can I check Dubai real estate transactions?"}
Start with the [official DLD Real Estate Data interface](https://dubailand.gov.ae/en/open-data/real-estate-data/). For a reproducible comparison, save the exact filters, raw response and access time, then name whether a count refers to rows, distinct transaction numbers or another returned field.
:::
:::faq-item{q="Does null mean zero in DLD transaction data?"}
No. In this audit, null means the exact returned JSON value is `null`. Numeric zero, an empty string and a missing key are separate states.
:::
:::faq-item{q="Which DLD fields had no nulls in this capture?"}
Eleven declared fields had 0 literal nulls: `ACTUAL_AREA`, `AREA_EN`, `GROUP_EN`, `INSTANCE_DATE`, `IS_FREE_HOLD_EN`, `IS_OFFPLAN_EN`, `PROCEDURE_AREA`, `PROP_TYPE_EN`, `TRANSACTION_NUMBER`, `TRANS_VALUE` and `USAGE_EN`.
:::
:::faq-item{q="Is the 2 October extraction a final September total?"}
No. It is a response captured on 2 October 2026 for the declared 1 to 30 September filter. The public DLD interface did not expose a formal finalisation boundary when accessed that day.
:::
::::

:::callout{variant="note" title="Keep the transaction audit current"}
Subscribe for the next quarterly report and the next reproducible DLD data check.
:::