Property Address Field Seperation

[RegMellon]

In some cases it is important to separate the address into its pieces (Address, City, State, Zip). Could the spec be updated to recommend these fields instead of one combined address field.

[TRIBUSeric]

Or have one field for combined address and ones for Add/City/State/Zip separated if that can be done.

[RegMellon]

Concatenating all pieces together should give you the same effect. I would suggest if a provider can't separate the address they place it all in lead_property_address, however if they have the fields already separate they place it in "lead_property_address", "lead_property_city", "lead_property_state", and "lead_property_zip".

[RegMellon]

This also applies to the name filed why is there not a first name and last name?

[EBashkoff]

For these issues regarding breaking out existing fields into more specific fields, the V1.0 spec does allow for things like custom fields:

        <meta name="lead_first_name"   content="John" />
        <meta name="lead_last_name"  content="Smith" />
        <meta name="lead_street_number"  content="100" />
        <meta name="lead_street_name"  content="Main St." />
        <meta name="lead_city"  content="Anytown" />
        <meta name="lead_state"  content="NY" />
        <meta name="lead_zip"  content="10001" />

As to whether all of these fields should be part of the "standard" set of fields, this would be up for discussion. Perhaps in a later version of this spec, we could have a current field such as lead_name act as a fallback if the first and last names were not available as two distinct fields. We could consider a similar fallback scheme for the address parts.

[RegMellon]

Well same thing here as in the agent information issue. If the fields are broken out in the email but not in the meta tag, traditional parsing still must be done. Even in the case of address if you use the meta tag and need the address parts you have to do further parsing on the address.