By having more field types that are practically equivalent to UNKNOWN fields we may be able to improve the field detection. 

In later stages, we can exercise veto against the server side votes if necessary.
Exp: If the heuristic says it's a quantity and the server says it's an expiration date, pick the quantity and take no action for the field (because it's practically a subset of an UNKNOWN field.)

Suggested field types:

-- Birthday (or non-expiration dates in general, such as flight date, booking date, etc. They usually have day as well as month and year.)
-- Quantity/Size/Height (vs exp month)
-- Search Term

We already have phone extension.

 

By having more field types that are practically equivalent to UNKNOWN fields we may be able to improve the field detection. 

Right now, if the heuristics mark a field as UNKONWN, the server's vote would overwrite the heuristics, even if the percent of votes are not large enough. By adding these fields we can avoid this.

Suggested field types:

-- Birthday (or non-expiration dates in general, such as flight date, booking date, etc. They usually have day as well as month and year.)
-- Quantity/Size/Height (vs exp month)
-- Search Term

We already have phone extension.

 

By having more field types that are practically equivalent to UNKNOWN fields we may be able to improve the field detection. 

Right now, if the heuristics mark a field as UNKONWN, the server's vote would overwrite the heuristics, even if the percent of votes are not large enough. By adding these fields we can avoid this.

Suggested field types:

-- Birthday (or non-expiration dates in general, such as flight date, booking date, etc. They usually have day as well as month and year.)
-- Quantity/Size/Height (vs exp month)
-- Search Term
-- Promo code

We already have phone extension.

 

By having more field types that are practically equivalent to UNKNOWN fields we may be able to improve the field detection. 

Right now, if the heuristics mark a field as UNKONWN, the server's vote would overwrite the heuristics, even if the percent of votes are not large enough. By adding these fields we can avoid this.

Suggested field types:

-- Birthday (or non-expiration dates in general, such as flight date, booking date, etc. They usually have day as well as month and year.)
-- Quantity/Size/Height (vs exp month)
-- Search Term
-- Promo code
-- Title

We already have phone extension.

 

By having more field types that are practically equivalent to UNKNOWN fields we may be able to improve the field detection. 

Right now, if the heuristics mark a field as UNKONWN, the server's vote would overwrite the heuristics, even if the percent of votes are not large enough. By adding these fields we can avoid this.

Suggested field types:

-- Birthday (or non-expiration dates in general, such as flight date, booking date, etc. They usually have day as well as month and year.)
-- Quantity/Size/Height (vs exp month)
-- Search Term
-- Promo code
-- Title
-- P.O. Box

We already have phone extension.

 

By having more field types that are practically equivalent to UNKNOWN fields we may be able to improve the field detection. 

Right now, if the heuristics mark a field as UNKONWN, the server's vote would overwrite the heuristics, even if the percent of votes are not large enough. By adding these fields we can avoid this.

Suggested field types:

-- Birthday (or non-expiration dates in general, such as flight date, booking date, etc. They usually have day as well as month and year.)
-- Quantity/Size/Height (vs exp month)
-- Search Term
-- Promo code
-- Title
-- P.O. Box
-- Price (See Tommy's comment.)

We already have phone extension.