Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Currency: Common currency reference conversion #4205

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

sigma-software-prebid
Copy link

@sigma-software-prebid sigma-software-prebid commented Feb 13, 2025

🔧 Type of changes

  • new bid adapter
  • update bid adapter
  • new feature
  • new analytics adapter
  • new module
  • bugfix
  • documentation
  • configuration
  • technical debt (test coverage, refactoring, etc.)

✨ What's the context?

#3566

🧠 Rationale behind the change

The Prebid.js currency module is able to cross convert currencies using USD (or GBP) as a common currency reference. This feature is not currently implemented in PBS Go, so the following error exists:
Unable to convert from currency NOK to desired ad server currency SEK.

In this PR we implement the common currency reference conversion logic (FindConversionRate method) in the currency package.

Related change in PBS Java

🧪 Test plan

New functionality is covered by TestGetRate_FindConversionRate unit test in currency/rates_test.go.

Closes prebid#3566

The Prebid.js currency module is able to cross convert currencies using USD (or GBP) as an intermediate.
This feature is not currently implemented in PBS Go, so the following error exists:
 'Unable to convert from currency NOK to desired ad server currency SEK'.
In this PR we implement the cross currency conversion logic through
an intermediate currency as a part of the GetRate method in the currency package.
Copy link
Contributor

@guscarreon guscarreon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take the conversion rates shown below:

	rates := NewRates(map[string]map[string]float64{
		"USD": {
		    "CAD": 0.90,
		    "MXN": 20.00,
		    "JPY": 50.00,
		},
		"MXN": {
		    "EUR": 0.05,
		},
	})

MAybe it's just me but, from "intermediate conversion" I would think that I'd be able to convert USD to EUR via MXN. In other words, convert from USD to MXN first, followed by a second conversion from MXN to EUR (USD -> MXN -> EUR) but, with the logic implemented in this pull request, that's not the case, right? The implemented logic would help me say, convert from Canadian Dollars to Japanese Yens (CAD -> JPY) that are both found under USD.

  1. Do you intend to implement USD -> MXN -> EUR conversions too?
  2. If not, should we rename this type of conversion to "common currency reference conversion" or something of sorts? Or do you agree with the naming?

if fromPresent {
return toConversion / fromConversion, nil
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move lines 51 to 60 to their own function and code a table-driven test in currency/rates_test.go?

@sigma-software-prebid
Copy link
Author

Take the conversion rates shown below:

	rates := NewRates(map[string]map[string]float64{
		"USD": {
		    "CAD": 0.90,
		    "MXN": 20.00,
		    "JPY": 50.00,
		},
		"MXN": {
		    "EUR": 0.05,
		},
	})

MAybe it's just me but, from "intermediate conversion" I would think that I'd be able to convert USD to EUR via MXN. In other words, convert from USD to MXN first, followed by a second conversion from MXN to EUR (USD -> MXN -> EUR) but, with the logic implemented in this pull request, that's not the case, right? The implemented logic would help me say, convert from Canadian Dollars to Japanese Yens (CAD -> JPY) that are both found under USD.

  1. Do you intend to implement USD -> MXN -> EUR conversions too?
  2. If not, should we rename this type of conversion to "common currency reference conversion" or something of sorts? Or do you agree with the naming?

@guscarreon our intention was to fulfil the feature #3566 where it has been mentioned as an intermediate currency.

Moreover, we have investigated the implementation in PBS Java and Prebid.js and based on the findings we wanted to be as close to "spec" as possible in order not to run into inconsistency between implementations - Go and Java versions being nearly identical and Prebid.js with minimal differences. However, I agree that common currency reference conversion name would fit better.

Also, I guess if we want to make more functional implementation it would be much better to extend conversion tables either to n*n currency mapping to minimize runtime efforts (plain lookup instead of looping) or make all the logic via one explicit common currency, but then this issue would have a bit wider scope and all 3 implementation between different Prebid versions would have different logic implemented.

What do you think?

@guscarreon
Copy link
Contributor

Take the conversion rates shown below:

	rates := NewRates(map[string]map[string]float64{
		"USD": {
		    "CAD": 0.90,
		    "MXN": 20.00,
		    "JPY": 50.00,
		},
		"MXN": {
		    "EUR": 0.05,
		},
	})

MAybe it's just me but, from "intermediate conversion" I would think that I'd be able to convert USD to EUR via MXN. In other words, convert from USD to MXN first, followed by a second conversion from MXN to EUR (USD -> MXN -> EUR) but, with the logic implemented in this pull request, that's not the case, right? The implemented logic would help me say, convert from Canadian Dollars to Japanese Yens (CAD -> JPY) that are both found under USD.

  1. Do you intend to implement USD -> MXN -> EUR conversions too?
  2. If not, should we rename this type of conversion to "common currency reference conversion" or something of sorts? Or do you agree with the naming?

@guscarreon our intention was to fulfil the feature #3566 where it has been mentioned as an intermediate currency.

Moreover, we have investigated the implementation in PBS Java and Prebid.js and based on the findings we wanted to be as close to "spec" as possible in order not to run into inconsistency between implementations - Go and Java versions being nearly identical and Prebid.js with minimal differences. However, I agree that common currency reference conversion name would fit better.

Also, I guess if we want to make more functional implementation it would be much better to extend conversion tables either to n*n currency mapping to minimize runtime efforts (plain lookup instead of looping) or make all the logic via one explicit common currency, but then this issue would have a bit wider scope and all 3 implementation between different Prebid versions would have different logic implemented.

What do you think?

@sigma-software-prebid thank you for the clarification. I agree with catching up to PBS-Java and Prebid.js. One final question: can we, as stated in a comment on my previous review above, move lines 51 to 60 in currency/rates.go to their own function and code a table-driven test in currency/rates_test.go? Let me know if you agree with this approach

@sigma-software-prebid sigma-software-prebid changed the title Currency: Intermediate rate logic Currency: Common currency reference conversion Mar 7, 2025
@sigma-software-prebid
Copy link
Author

Take the conversion rates shown below:

	rates := NewRates(map[string]map[string]float64{
		"USD": {
		    "CAD": 0.90,
		    "MXN": 20.00,
		    "JPY": 50.00,
		},
		"MXN": {
		    "EUR": 0.05,
		},
	})

MAybe it's just me but, from "intermediate conversion" I would think that I'd be able to convert USD to EUR via MXN. In other words, convert from USD to MXN first, followed by a second conversion from MXN to EUR (USD -> MXN -> EUR) but, with the logic implemented in this pull request, that's not the case, right? The implemented logic would help me say, convert from Canadian Dollars to Japanese Yens (CAD -> JPY) that are both found under USD.

  1. Do you intend to implement USD -> MXN -> EUR conversions too?
  2. If not, should we rename this type of conversion to "common currency reference conversion" or something of sorts? Or do you agree with the naming?

@guscarreon our intention was to fulfil the feature #3566 where it has been mentioned as an intermediate currency.
Moreover, we have investigated the implementation in PBS Java and Prebid.js and based on the findings we wanted to be as close to "spec" as possible in order not to run into inconsistency between implementations - Go and Java versions being nearly identical and Prebid.js with minimal differences. However, I agree that common currency reference conversion name would fit better.
Also, I guess if we want to make more functional implementation it would be much better to extend conversion tables either to n*n currency mapping to minimize runtime efforts (plain lookup instead of looping) or make all the logic via one explicit common currency, but then this issue would have a bit wider scope and all 3 implementation between different Prebid versions would have different logic implemented.
What do you think?

@sigma-software-prebid thank you for the clarification. I agree with catching up to PBS-Java and Prebid.js. One final question: can we, as stated in a comment on my previous review above, move lines 51 to 60 in currency/rates.go to their own function and code a table-driven test in currency/rates_test.go? Let me know if you agree with this approach

@guscarreon thank you for the feedback. We have extracted the above-mentioned code into the separate FindConversionRate method and adjusted the PR title accordingly.

@bsardo bsardo assigned SyntaxNode and guscarreon and unassigned guscarreon and bsardo Mar 11, 2025
Copy link
Contributor

@guscarreon guscarreon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sigma-software-prebid thank you for addressing my feedback. LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants