Skip to content

Market research model

Paul Sohn edited this page Mar 31, 2017 · 10 revisions

Market Research model workflow

A market research workflow would involve one or more steps in an UrbanSim simulation to provide useful input to the real estate pro forma analysis. Some of the benefits of such a workflow would be:

  • Provide an endogenous feedback loop between real estate feasibility analysis, and conditions in the market (e.g. absorption, vacancy, prices). This would help provide a more organic, market-driven process within the simulation.
  • Add an element of speculative behavior to simulated real estate developers; this element is, we think, realistic but is not really modeled
  • A mechanism for filtering out inputs to the feasibility model, to (potentially drastically) improve speed and enable simulation at smaller time steps

Current situation

Which buildings get built in each simulation year is currently determined by two models:

  • The pro forma step calculates profitability for all parcels in the region. The primary endogenous inputs are 1) the current rents of the parcels, and 2) the typical rents for each use for each parcel. This does not currently use information about housing supply other than indirectly through prices.
  • The developer step selects parcels for development. Parcels are assigned a development probability based on results from pro forma. A target number of units to build is assigned. This is either an input, or calculated using the number of existing agents, number of existing units, and a target vacancy. Finally, enough buildings are built to match that unit target.

Problems with the current situation

  • No feedback about demand/supply match other than through prices
  • All parcels are assessed for feasibility in every year (computationally wasteful)

Basic mechanics

This model workflow is called a workflow because it involves several different steps at different points in the simulation.

Data collection

We have to record information at certain time steps in the model to perform later market research calculations. This might include, for instance, information about vacancy or prices at the building scale at a point in time. We can save these as Orca columns to be used in later steps.

For example:

  • For each building in the buildings table (to calculate after hedonic regression):

    • Residential price per square foot (this and each column below tagged with the simulation year)
    • Office price per square foot
    • Industrial price per square foot
    • Retail price per square foot
  • For each building in the buildings table (to calculate after location choice models):

    • Used residential space (this and each column below tagged with the simulation year)
    • Total residential space
    • Used non-residential space
    • Total non-residential space

These are simple, and prices are already calculated, but not saved with each simulation year. Saving these results in this way allows us to calculate trends later.

Market research calculations

These calculations could all be housed within a market research model class, accessed through an Orca step right before feasibility calculations in each year. Specific calculations could include:

  • Absorption
  • Absorption trend
  • Neighborhood price trends
  • Land residual
  • "Hot market" identification

Each of these needs to be further specified.

Filter input into feasibility

One advantage of using a preliminary market research model is that we can smartly filter out parcels from the feasibility step that have little to no chance of seeing new development. This part of the model should return a reduced table of development projects: only those that have a reasonable chance of getting developed.

This could take into account any or all of the above calculations, and we need to build out a model to decide what is not passed to feasibility. It could a stochastic process based on some kind of composite score from the above calculations.

Factor into feasibility calculations

Some of the market research outputs should also serve as inputs to the feasibility model to actually factor into the profit calculation for each development site. For example, lower absorption should lower the revenue for a potential building, changing its profitability.

This interface needs to be carefully designed for each market research calculation.

Revised developer model

The number of developments that get built are determined in the developer model. Currently, the rule is:

  • If the number of target units (derived from target vacancy) is 0, don't build anything
  • If the number of target units is greater than the number of profitable buildings, build everything
  • If the number of target units is > 0 and < the number of profitable buildings, select buildings by probability (based on profitability)

New logic should look like this:

  • If no development caps: build everything above a certain minimum profitability
  • If development caps: for each cap,
    • Select buildings in relevant geography/subtype based on probability

Data collection and calculation timeline

A general timeline should be:

  • Year X
    • Transition, hedonic models, LCMs
    • (Data collection: vacancy, prices for all buildings, tag as year X)
    • (Market research: calculate absorption for new buildings from year X-1)
    • (Market research: tag parcels as being in a "hot" neighborhood based on change between year X-1 and X)
    • (Market research: etc)
    • Pro forma
    • Developer
    • (Data collection: new buildings tagged as built in year X)
  • Year X+1
    • Transition, hedonic models, LCMs
    • (Data collection: vacancy, prices for all buildings, tag as year X+1)
    • (Market research: calculate absorption for new buildings from year X)
    • (Market research: tag parcels as being in a "hot" neighborhood based on change between year X and X+1)
    • (Market research: etc)
    • Pro forma
    • Developer
    • (Data collection: new buildings tagged as built in year X+1)
Clone this wiki locally