How to change numbers display in Marketo

[Ronen-Was-SRpro]

* Note – this is a technical article for Marketo experts, if you have any questions do not hesitate to contact us.

This article explains how to change the display of numbers in Marketo. Usually, we store numbers in fields with a ‘float’ field type. In these cases, when we try to use them as a token in an email, the display will be: 1000. The following steps will change the display to: 1,000.

1. Go to the relevant program (the one you would like to send the email from) and click "My Tokens" tab.

2. Drag and drop the "Email Script" token type to the main folder.

3. Give a name to the token and click edit.

4. Search the field you need to change in the right tab and drag it to the main window (the field is usually under "Person" headline). This is what you will see after dragging:

5. Change the line and add the following (with the original field in it): $number.integer($lead.Credit_Ballance__c) and save.

6. Click “save" again.

7. Use the new token in the email.

GOOD LUCK!

How to change numbers display in Marketo - Responsive  Marketing

[SanfordWhiteman]

You should never, ever use the Float datatype if the data is intended to be precise.

It doesn't matter if you convert the Float to Int for display -- this is the wrong datatype and you can never recover the correct value once stored as Float.

For what looks to be a money value in your example, you should use Int, multiplied by 10^{number of decimal places} if desired.  (Do not use the Marketo Currency datatype, either, as it is merely another name for binary32/single float and leads to data disasters.)

[SanfordWhiteman]

P.S. Here's an easy proof of why Floats are an actively-happening disaster.

Set a Float field to

  16777217

then change it again to

  16777218

Now check your Activity Log.

You'll see the value is still

  16777217

and you'll only see the first Data Value Changed event, not the second.

The reason for this is that 16777218 (like billions of other integers) cannot be represented as a binary32/single float without data loss. Its single float value is 16777217, so you can't "change" the value from one to the other in the database. (The translation from 16777218 to 16777217 is referred to as "rounding," but you have to know the underlying math to understand how this type of rounding works, as it is very unlike decimal rounding.)

As a result there are countless data value changes on the front end that will never register as changes on the back end, and countless values that will appear to be set but will be represented differently in token output -- and will be matched differently in Smart Lists.

I've been meaning to finish this blog post for awhile, maybe now I'll get back to it but the gist of it is above...

Christina Zuniga (if you didn't see this earlier)

[Josh_Hill9]

wow.

Is this an Idea or was sent to Support?

[SanfordWhiteman]

Well, at least as regards the explicit Float datatype, it's not really a bug, so nothing can be done about it. One might well wonder why a 32-bit single Float exists as an option, since it's an outdated type except in highly memory-constrained scenarios. But the thought is presumably that people must know what Float is good for (if anything!) before choosing that option from the dropdown.

The Currency datatype, on the other hand, being a single float under the hood I do consider a bug, since the name suggests that it's suitable for money values when it most certainly is not. Even if it were a double float it would still be wrong for money.  But I want to get my blog post done before referencing it in an Idea.